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FOREWORD  TO  CHANGE  3 


Many  changes  have  taken  place  in  the  AEGIS  software  engineering  process 
improvement  arena  since  the  original  document  was  published.  They  have  been 
documented  in  year-end  reports.^ 

Current  SEPG  members  are  Edward  J.  Dudash,  Chairperson,  N20P;  John  R. 
Maphis,  Deputy  Chairperson,  N20P;  Mary  Ann  Strock,  F42:  Linda  F.  George,  N81;  David 
E.  McConnell,  N86:  Kenneth  M.  Novell,  N92;  Charles  B.  Graham  and  Charles  H.  Sperry, 
Computer  Sciences  Corporation;  and  Paul  B.  Garnett  and  Larry  K.  Walker,  LOGICON, 
Syscon  Corporation. 

An  evaluation  of  the  most  efficient  way  to  use  the  limited  resources  available  to 
AEGIS  led  to  the  dissolution  of  the  Software  Engineering  Process  Committee  on  10 
March  1995.^  The  role  of  that  organization  has  been  absorbed  by  other  groups 
functioning  as  action  teams. 

Change  3  was  prepared  by  Mr.  McConnell  and  Mr.  Sperry.  It  was  reviewed  on  13 
March  1995  by  representatives  from  the  NSWCDD  AEGIS  Organizations. 

During  the  time  span  over  which  this  document  was  prepared,  some  organizations 
changed  their  names;  e.g.,  Lockheed  Martin  (formerly  Martin  Marietta  Corporation)  and 
System  Test  and  Evaluation  (formerly  Integration)  Branch.  The  SEPG  believes  that  the 
level  of  understanding  enjoyed  by  SEPD  users  does  not  require  that  these  changes  be 
implemented  throughout  the  document;  therefore,  they  are  postponed  to  some  future 
revision. 
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EDWARD  J.  DODASH 


Chairperson,  Software  Engineering 
Process  Group 


0, 

D.  ROBINSON 
Assistant  Program  Manager 
for  Computer  Program 
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System  Definition 

In  the  System  Definition  Phase,  analysis  is  performed  to  define  requirements  the 
system  must  support  and  to  validate  new  functional  capabilities.  System  requirements 
are  defined  and  allocated  to  elements,  and  functional  interface  data  are  identified. 
System  test  and  simulation  requirements  are  determined.  The  conduct  of  a  successful 
System  Design  Review  (SDR),  marked  by  PMS400B  authorization  to  proceed,  closes 
this  phase.  This  review  is  an  assessment  of  the  completeness  of  system  design,  and 
a  review  of  the  allocation  of  requirements  from  the  standpoint  of  optimization, 
traceability,  correlation,  completeness,  consistency,  and  risk.  Authorization  to  proceed 
denotes  approval  of  the  system  engineering  aspects  as  well  as  programmatic  scope, 
schedule,  and  resource  requirements. 

Element  Definition 

In  the  Element  Definition  Phase,  all  system  requirements  allocated  to  the 
elements  are  fully  analyzed,  and  computer  program  performance  specifications  and 
interface  design  specifications  are  developed;  elements  prepare  element  development 
plans.  Training,  logistics,  simulator,  and  simulation  requirements  are  defined.  A 
Preliminary  Design  Review  (PDR)  is  held  where  progress,  plans,  and  allocation  of 
requirements  are  reviewed  and  validated  by  PMS400B  and  authorization  to  proceed  is 
given. 

High-Level  Design 

In  the  High-Level  Design  Phase,  the  physical  architecture  and  high-level  design 
of  the  computer  programs  are  developed  and  documented.  Requirements  are  allocated 
to  modules,  common  data,  and  intermodule  interfaces.  Design  is  formulated  by 
representing  the  impacts  upon  procedural  interfaces  in  terms  of  data  flow,  control  flow, 
procedural  hierarchy,  and  data  structure.  Approval  is  obtained  for  non-Mk7  interfaces. 
Program  performance  and  interface  design  specifications  are  prepared  for  a  Critical 
Design  Review  (CDR),  where  preliminary  data  base  and  program  design  documentation 
are  also  presented  for  PMS400B  approval.  Authorization  to  proceed  indicates  the 
physical  architecture  and  high-level  design  meet  requirements,  design  documentation 
is  valid  and  sufficient  to  guide  detailed  design,  and  the  interface  working  groups  have 
approved  interface  requirements. 

Build  Implementation  Phase 

In  the  Build  Implementation  Phase,  each  unit  identified  during  the  High-Level 
Design  Phase  is  developed  and  checked  out.  Depending  on  the  nature  of  the 
computer  program  change  requests  (CPCRs),  the  changes  to  the  computer  program 
may  or  may  not  merit  test  procedure  generation;  but  all  changes  are  designed,  coded, 
and  unit  tested.  At  the  conclusion  of  each  build,  a  Build  Implementation  Review  (BIR) 
is  conducted  and  the  results  of  all  build  activities  are  discussed.  The  BIR  for  the  final 
build  summarizes  the  disclosures  of  the  previous  BIRs,  and  serves  as  the  control  event 
that  signals  the  end  of  the  Build  Implementation  Phase.  The  report  documenting  the 
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final  BIR  is  the  control  event  that  ensures  completeness  of  all  code  and  unit  testing 
activities  and  serves  as  a  status  report  for  Baseline  Management. 

Element  Test 

The  Element  Test  Phase  begins  with  a  control  event,  Element  Test  Disclosure 
Review  (ETDR),  where  element  test  planning,  test  design,  and  test  procedure 
documentation  are  reviewed  for  completeness  and  the  readiness  of  ACSIS  required 
simulators  and  support  computer  programs  is  determined.  Following  authorization  to 
proceed,  the  elements  conduct  multi-element  integration  and  testing,  stress  and 
regression  testing,  and  validation  of  all  interface  design  specification  (IDS),  prime  item 
development  specification  (PIDS),  and  computer  program  performance  specification 
(PPS)  changes.  During  this  time  period,  user  documentation  and  system  test 
procedures  are  prepared.  Completion  of  the  control  event.  Element  Readiness  Review 
(ERR),  certifies  that  element  development  is  essentially  complete  and  that  the  computer 
programs  are  ready  for  the  System  Test  Phase. 

System  Test 

The  System  Test  Phase  begins  with  a  control  event.  System  Test  Disclosure 
Review  (STDR),  where  System  Test  and  Integration  discloses  its  test  plan,  test  design, 
etc.  Testing  is  conducted  for  regression,  stress,  and  combat  system  integration;  and 
tests  and  test  observation  reports  are  analyzed.  Concurrently,  all  ACS  and  AWS 
changes  are  validated.  The  phase  ends  with  the  convening  of  a  Computer  Program 
Certification  Panel  (CPCP)  and  Program  Office  (NOS)  decision  as  to  the  program’s  and 
its  documentation’s  readiness  for  installation  in  the  fleet  and  at  shore  activities. 

Operation 

In  the  Operation  Phase,  computer  programs  and  documentation  (both  AWS  and 
non-Mk7)  are  installed  on  board  ship  and  tested,  and  crew  training  and  user  support 
is  conducted,  including  crew  indoctrination.  The  installation  is  reviewed  with  the  ship’s 
Commanding  Officer,  Combat  System  Officer,  or  System  Test  Officer.  Problem  reports 
are  investigated  and  resolved.  NSWCDD  continues  to  provide  each  ship  with  this  kind 
of  support  for  baseline  upgrade  installations  and  in  response  to  CPCRs. 
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Management  Support 

Management  support  is  not  a  separate  phase  in  that  it  is  bounded  by  control 
events:  rather  its  activities  range  throughout  the  entire  life  cycle.  It  is  a  convenience 
for  grouping  non-phase-specific  activities  as  personnel  management,  configuration 
management,  quality  assurance,  software  engineering  process  improvement,  metrics, 
and  management  administration. 


AEGIS  ORGANIZATIONS 

AEGIS  Organizations  are  all  the  participants  in  the  NSWCDD  AEGIS  software 
engineering  process.  They  are  named  as  performers  or  participants  in  the  activities 
discussed  in  detail  in  each  phase. 


Sponsor 

AEGIS  Program  Manager^  PMS400 

ACS  Change  Control  Board  CCB 

Interface  Control  Working  Group  ICWG 

Warfare  Commanders  PMS400 

Director,  Technical  Division  PMS400B 

Technical  Director  PMS400B 

AEGIS  Combat  System  Engineer  PMS400B3 

AEGIS  Baseline  Manager  PMS400B32 

Director,  Fleet  Introduction  Division  PMS400F 

Destroyer  Acquisition  PMS400D 

System  Acquisition  PMS400G 

Technical  Representative  PMS400N 


Development  Agent 

Martin  Marietta  Corporation,  Government  Electronics 
Systems  (Formerly  Government  Electronic 
Systems  Division  (GESD)) 

Software  Implementation  Board  SIB 


Defense  Plant  Representative  Offices  DPRO 

Engineering,  Test,  and  Support  Organizations 
Applied  Physics  Laboratory,  Johns 

Hopkins  University  APL 


Mn  this  document,  Program  Manager  refers  to  PMS400;  Program  Office,  NSWCDD  NOS. 
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Combat  System  Engineering 


Development  Site 

CSEDS 

AEGIS  Combat  Systems  Center 

ACSC 

AEGIS  Training  Support  Group 

ATSG 

AEGIS  Test  Team,  Pascagoula 

ATT/P 

AEGIS  Test  Team,  Bath 

ATT/B 

AEGIS  In-Service  Engineering  Agent 

Port  Hueneme  Division,  Naval  Surface  Warfare 

Center 

PHDNSWC 

AEGIS  Ship  Personnel 

— 

NSWCDD  Organizations 

Information  Security 

C9 

SPY  Radar  System 

F42 

AEGIS  Data  Center 

E231 

Combat  Systems  Department 

N 

AEGIS  Program  Office,  Program  Office 

NOS 

Core  Team 

LSEA  Configuration  Control  Board  (CCB) 
Assistant  Program  Manager  for  Life 

NOS 

Support  Engineering 

N054 

Assistant  Program  Manager  for 

Computer  Program  Engineering 

N055 

Combat  Systems  Engineering 

N20 

Baseline  Manager,  Baseline  Management 

N20B 

Software  CM  Manager 

N20C 

AWS  Change  Review  Board 

N20C 

Software  Engineering  Process  Group 

N20P 

Systems  Control  and  Operational  Support 

N21 

Baseline  Control 

N21 

Documentation  Management 

N21 

Fleet  Support 

N21 

System  Quality  Assurance 

N21 

Installation  Team,  Installation  Manager 

N21 

System  Engineering 

N24 

Combat  Systems  Test  and  Evaluation 

N25 

Engineering  and  Ship  Integration 

N26 

Combat  Systems  Engineering  Environment 

N80 

Systems  Simulation 

N81 

Facilities  Engineering 

N82 

Systems  Readiness 

N85 

Operational  Readiness  and  Test 

N85 

Computer  Systems 

N86 

AEGIS  Computer  Center 

N86 
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AEGIS  Tape  Library  N86 

Program  Generation  N86 

AWS  Change  Review  Board  Configuration 
Management  N87 

Combat  System  Configuration  Management  N87 
Warfare  Control  N90 

Combat  Direction  Systems  N91 

Command  and  Decision  N91 

AEGIS  Display  System  N91 

AEGIS  Weapons  and  Fire  Control  N92 

Fire  Control  System  N92 

Weapon  Control  System  N92 

Element,  Elements 
Branch  Heads 
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LIST  OF  ABBREVIATIONS 

ABAM-AEGIS  Weapon  System  Computer  Program  Baseline/Document 
Applicability  Matrix 
ACC-AEGIS  Computer  Center 

ACCESS-AEGIS  Configuration  Control  and  Engineering  Status  System 

ACD-AEGIS  Control  Document 

ACPOT-AEGIS  Computer  Program  Operability  Test 

ACS-AEGIS  Combat  System 

ACSC-ACS  Center 

ACSIS-ACS  Interface  Simulation,  Simulator 
ACTS-AEGIS  Combat  Training  System 
ADAR-AEGIS  Data  Reduction 
ADC-AEGIS  Data  Center 
ADDS-AEGIS  Design  Description  System 
ADS-AEGIS  Display  System 

AlCR-ACSIS  Interface  Message  Specification  Change  Request 

APO-AEGIS  Program  Office 

ASDS-ACTS  Scenario  Development  System 

ASWCS-Anti-Submarine  Warfare  Control  System 

ATC-AEGIS  Training  Command 

ATES-AEGIS  Tactical  Executive  System 

ATSG-AEGIS  Training  Support  Group 

ATT-AEGIS  Test  Team 

ATUS-AEGIS  Tactical  Utility  System 

AWS-AEGIS  Weapon  System 

BDF-Baseline  Development  Folder 

BL-Baseline 

CAST-Computer  Aided  Submode  Training 
C&D— Command  &  Decision 
CCB-Change  Control  Board 
CDD— Configuration  Definition  Document 
CDR-Critical  Design  Review 
CDRL-Contract  Data  Requirement  List 
Chg-Change 

CLASS-CAST  Lesson  Authoring  System 

CM-System  Configuration  Management  Branch 

CMI-CM  Instruction 

CMS-Compiler  Monitor  System 

Concpt-Concept 

CP-Computer  Program 

CPC-CP  Change 

CPDP-CP  Development  Plan 

CPCP-Computer  Program  Certification  Panel 

CPCR-CPC  Request 

CPDD-CP  Description  Document 

CPM-CP  Management 

CPQT-CP  Qualification  Test 

CPS-Computer  Programming  Standard 

CPTIP-CP  Test  &  Integration  Plan 

CPTS-CP  Test  Site 

CRB-Change  Review  Board 

CRECG-Computer  Room  Error  Code  Guide 
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CSC-Computer  Sciences  Corporation 
CSE-CS  Element 

CSEDS.-CS  Engineering  Development  Site 

CTR-Code  and  Test  Review 

DBDD-Data  Base  Design  Document 

DCMAP-Defense  Contractor  Management  Area  Operations 

DDD~Delivery  Description  Document,  Detailed  Design  Document 

DDCR~Design  Document  Change  Request 

DDR-Detailed  Design  Review 

Develop-Deveiopment 

DID-Data  Item  Description 

DMI-Documentation  Management  Instruction 

Doc/Docs-Document/Documents 

DOD-STD-Department  of  Defense  Standard 

DPRO-Defense  Plant  Representative  Offices 

DXDR-Data  Extraction,  Data  Reduction 

EAT-Engineering  Analysis  Team 

ECCB-Element  Change  Control  Board 

ECN-Engineering  Change  Notice 

ECP-Engineering  Change  Proposal 

ELMT  LDR-Element  Leader 

Elmt-Element 

EQT-Engineering  Qualification  Test 
ERR-Element  Readiness  Review 
ERT-Element  Design  Review  Team 
ESOP-Element  Standard  Operating  Procedure 
ETDR— Element  Test  Disclosure  Review 
FCS-Fire  Control  System 
FDF-Functional  Development  Folder 
FLCR-Film  label  change  request 
Func-Functional 

GESD-Government  Electronic  System  Division 

ICR-Interface  Design  Specification  Change  Request 

ICWG-Interface  Control  Working  Group 

IDS-Interface  Design  Specification 

IMS-Interface  Message  Specification 

IPR-ln-Process  Review 

ISEA-ln-Service  Engineering  Agent 

JCL-Job  Control  Language 

LCP-Lesson  Control  Program 

LGEN-Lesson  Generator 

LGP-Lesson  Generator  Program 

Lmtns— Limitations 

LPD-Load  Program  Description 

LPDD— LPD  Document 

LSEA-Lifetime  Support  Engineering  Agent 

MDF-Module  Development  Folder 

MEIT  P.M-MEIT  Pack  Management 

MEIT-Multi-Element  Test  &  Integration 

Mgmt-Management 

Mgr-Manager 

MPS-Master  Program  Save 
MTASS-Machine  Transferable  Support  Software 
NSWCDD-Naval  Surface  Warfare  Center  Dahlgren  Division 
OCP-Operational  Computer  Program 
Op,  Oper-Operational 
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OPNAV-Office  of  the  Chief  of  Naval  Operations 
OPP-Operating  Principles  and  Procedures 
Org-Organization,  Organizations 
ORTS-Operational  Readiness  Test  System 
PCR-Project  Commitment  Review 
PD-Publication  Directive 
PDD-Program  Design  Document 
PDR-Preliminary  Design  Review 
PDS-Program  Design  Specification 
PGE--Program  Generation  Environment 
Pgms-Programs 

PHDNSWC-Port  Hueneme  Division,  Naval  Surface  Warfare  Center 

PIDS-Prime  Item  Development  Specification 

PMA-Post-Mission  Analyzer 

PMO-Project  Management  Office 

PMS400-AEGIS  Program  Manager 

POA&M--Plan  of  Action  &  Milestones 

POM— Program  Objectives  Memorandum 

PPS-Program  Performance  Specification 

Prel/Prelim-Preiiminary 

Proc-Procedure 

QA-Quality  Assurance 

QAI-QA  Instruction 

QAP-QA  Procedure 

QRG-Quick  Reference  Guide 

Reqrs-Requirements 

Rpt/Repts-Report,  Reports 

SC-Specification  Change 

SCIB-Ship  Characteristics  and  Improvement  Board 
SCN-SC  Notice 

SCP-Support  Computer  Programs 
SDD-Software  Design  Document 
SDR-System  Design  Review 
SIB-Software  Implementation  Board 
Sim-Simulation 

SOP-Standard  Operating  Procedure 
Spec-Specification 
SRT-System  Design  Review  Team 
ST&E-System  Test  and  Evaluation 

ST&I-System  Test  and  Integration  (previous  name  of  ST&E) 
ST&ISOP-ST&I  SOP 

STCRB-Ship  Test  Configuration  Review  Board 
STDR-System  Test  Disclosure  Review 
STO-System  Test  Officer 
Sys-System 

Sys  Eng-System  Engineering 
TCP-Training  Control  Program 
TDS-Tactical  Disk  Save 
TOR-Test  Observation  Report 
TPCR-Test  Procedure  Change  Request 
V&V-Verification  and  Validation 
WCS-Weapon  Control  System 
WIP-WarfIghting  Improvement  Plan 
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USERS’  NOTES 

This  document  is  under  change  control  and  will  be  updated  by  change  pages  as 
the  process  evolves. 

The  data  flow  diagrams  (DFDs)  throughout  Part  II  are  depicted  by 
EXCELERATOR,  an  integrated  set  of  analysis  and  design  tools.  These  diagrams 
depict  application  activities,  data  storage  areas,  and  the  movement  of  information 
throughout  the  application.  They  also  represent  the  control  events  that  determine  when 
processes  or  phases  are  complete.  For  these  diagrams,  the  Gane  &  Sarson  notations 
were  used.  Some  of  the  conventions  used  in  the  diagrams  are  listed  below.  For  more 
information,  consult  the  Chairperson  of  the  SEPG. 

•  The  entire  AEGIS  Combat  System  (ACS)  is  represented  by  a  context 

diagram  which  depicts  the  interfaces  between  NSWCDD  and  the  external 
entities  (e.g.,  PMS400,  Government  Electronic  Systems,  APL, 

PHDNSWC). 

•  The  entire  AEGIS  Weapon  System  (AWS)  process  is  represented  by  a 
diagram  that  depicts  the  eight  NSWCDD  AEGIS  software  engineering 
phases,  the  external  control  events,  and  the  most  significant  products  of 
the  process. 

•  Each  of  the  eight  phases  is  represented  by  a  DFD  that  depicts  a  number 
of  processes  of  that  phase,  in  groupings  that  represent  the  major  activities 
of  the  phase,  control  events  occurring  during  the  phase,  and  key  products 
of  the  phase,  as  defined  by  the  process  model,  and  consistent  with  the 
AWS  diagram. 

•  Each  process  is  supported  by  activities,  specific  actions  that  are 
performed. 

•  Each  diagram  consists  of  processes,  data  stores,  data  flows,  and 
optionally,  external  entities. 

Processes  are  hierarchically  and  sequentially  numbered;  they  are 
actions  or  events  that  transform  inputs  into  outputs. 

Data  stores  are  collections  of  data  that  are  held  for  processing. 
Data  flows  represent  data  in  motion. 

External  entities  are  persons  or  groups  with  whom  the  system 
communicates. 
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Port  Hueneme  Division.  Naval  Surface  Warfare  Center  tPHDNSWC)  -  Formerly  Naval  Ship  Weapon 
Systems  Engineering  Center  (NSWSES),  In-Service  Engineering  Agent  (ISEA)  forCG47  Class  and  DDG 
51  Class  Ship  Combat  Systems. 

Preliminary  Operational  Description  -  Document  generated  by  System  Engineering  in  the  Project 
Definition  Phase. 

Prime  Item  Development  Specification  (PIPS)  (Type  B1)  -  Specification  prepared  to  practices  set  forth 
in  MIL-STD-490A.  It  states  the  requirements  for  the  design  or  engineering  development  of  a  complex 
item  such  as  a  missile,  aircraft,  radar  set,  fire  control  equipment,  etc.  PIDSs  for  components  of  the 
AEGIS  Weapon  System  (elements)  are  maintained  by  PMS400B. 

Print  Listing  -  The  sequence  of  instructions,  reports,  or  other  data  comprising  acomputer  program  output, 
usually  in  the  form  of  a  human-readable  printout. 

Program  Design  Document  (PDD)  -  A  document  providing  a  description  of  the  physical  architecture  of 
the  AWS  computer  programs,  the  functional  allocation  of  requirements,  and  the  high-level  design  of  the 
computer  programs.  The  PDD  also  includes  a  specification  of  the  impacted  computer  program 
interfaces,  and  identifies  the  inter-procedural,  inter-module,  and  module-to-operating  system 
interdependencies. 

Project  Commitment  Review  -  See  Design  Review  Process. 

Process  Model  -  A  framework  for  the  activities  required  to  perform  software  development  and  support. 
This  framework  specifies  the  inputs  and  outputs  of  activities,  the  sequence  and  criteria  to  begin  an 
activity,  and  the  criteria  required  to  complete  the  activity. 

Program  Performance  Specification  (PPS1  (Type  B51  -  A  document  providing  the  baseline  for  subsequent 
program  development.  It  specifies  the  operations  and  functions  the  element  computer  program  is  to 
perform,  and  the  provisions  for  quality  assurance  and  testing.  The  PPS  also  specifies  the  appropriate 
configuration  of  computer  equipment.  A  PPS  specifies  performance  requirements  but  not  the  plan  for 
implementation  (e.g.;  it  does  not  include  the  number  of  builds  planned  during  development).  For 
captured  programs,  as  much  original  performance  documentation  as  possible  is  retained  to  reduce  costs. 
New  or  modified  requirements  are  specified  in  change  pages  to  the  original  documentation.  See  MIL- 
STD-1679A. 

Publication  Directive  (PD)  -  A  cover  sheet  Documentation  Management  attaches  to  a  specification  or  an 
SCN  to  coordinate  the  approval  process  and  provide  an  audit  trail. 

QA  Audit  Report  (QA  Form  006)  -  A  QA  form  containing  information  relevant  to  QA  review  of  a  class, 
library,  computer  program  build,  export  to  tape,  or  CPCR. 

QA  Discrepancy  Report  -  A  report  issued  by  the  QA  group  leader  to  document  deficiencies  discovered 
during  QA  audits.  It  can  be  issued  to  document  non-conformance  to  QA  instructions  or  to  evoke 
corrective  action  for  substandard  products. 

QA/Element  Controlled  Library  -  An  automated  program  library  or  support  system  under  the  Joint  control 
of  QA  and  the  individual  element  that  stores  all  of  each  element’s  work  products  (e.g.,  source  code, 
object  code,  test  cases,  etc.).  The  system  may  operate  in  batch  or  interactive  mode,  or  both.  It  usually 
will  provide  for  multiple  versions  of  a  file,  with  one  version  of  each  tagged  as  the  production  version. 
Files  are  usually  provided  for  source  code,  object  code,  and  program  data.  The  QA/element  controlled 
library  is  managed  by  an  Element  Librarian.  The  QA/element  controlled  libraries  taken  together  make 
up  the  controlled  library  for  the  project. 
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QA  Verification  Notice  -  VAX  Mail  Message  sent  by  QA  to  the  element  stating  that  the  verification  of  their 
program  is  complete  and  ready  to  be  transferred  to  the  element  disk. 

Quality  Assurance  (QA)  -  (1)  A  planned  and  systematic  pattern  of  all  action  necessary  to  provide 
adequate  confidence  that  the  item  or  product  conforms  to  established  technical  requirements.  (2)  The 
process  or  activity  during  which  the  system  design  is  audited  to  determine  whether  it  represents  a 
verifiable  certifiable  specification,  and  during  which  test  plans  and  procedures  are  formulated  and 
implemented.  This  activity  ensures  the  technical  compliance  of  the  system-a  product-to  its 
requirements  and  design  specifications.  QA  is  an  independent  audit  review  of  all  products  to  ensure  their 
compliance  to  a  management-directed  standard  of  quality.  (3)  Guarantee  made  by  the  developer  to  the 
customer  that  the  system  meets  minimum  levels  of  acceptability.  The  criteria  for  acceptability  should 
be  mutually  agreed  upon,  measurable,  and  put  into  writing.  Primarily,  though  not  necessarily,  quality  is 
assured  through  some  form  of  testing. 

Radar  System  AN/SPY-1A(B.D)  -  Primary  air  and  surface  radar  for  the  AEGIS  Combat  System.  It  is  a 
multi-function  phased-array  radar  capable  of  search,  automatic  detection,  transition  to  track,  and  track 
of  air  and  surface  targets  located  in  preselected  coverage  volumes.  Digital  control,  high-power  output, 
and  advanced  signal  processing  techniques  are  used  to  provide  adaptive  search  and  multi-target 
tracking.  Capable  of  operating  in  both  heavy  clutter  and  ECM  environments.  Has  a  high  track  capacity 
and  is  effective  against  a  wide  spectrum  of  target  characteristics.  Communicates  with  the  SM-2  through 
its  flight  to  exchange  mid-course  guidance  commands  and  missile  status  messages. 

Request  Letter  -  A  letter  prepared  by  NOS  requesting  that  Martin  Marietta  generate  and  deliver  or 
transmit  computer  program  products  or  services  under  an  existing  contract. 

SC/ICR  Package  -  A  collection  of  related  pages  pertaining  to  an  AEGIS  SC  or  ICR  to  be  considered  or 
acted  upon  as  one  unit.  The  related  pages  are  derived  from  interface  design  specification  change 
requests  (ICRs)  or  specification  changes  (SCs).  The  change  package  is  initiated  by  the  AEGIS  element 
engineers  and  submitted  to  the  AEGIS  Change  Review  Board  for  approval.  Once  approved,  it  is 
incorporated  into  a  specification  or  specification  change  notice  (SCN). 

Ship  Availability  Schedule  -  A  procedural  plan  that  indicates  the  time  and  sequence  of  ships’  availability 
to  accept  new  or  upgraded  computer  program  installations.  This  schedule  is  compiled  by  N211  based 
on  Master  Planning  Schedules  issued  by  the  AEGIS  Program  Manager  (PMS400). 

Shipboard  Installation  Plan  -  A  schedule  generated  by  the  Installation  Manager  that  lists  all  necessary 
steps  and  procedures  needed  to  implement  shipboard  computer  program  installation. 

Software  Design  Document  -  A  document,  prepared  to  a  standard,  that  describes  the  design  of  a 
software  system  or  component.  Contents  may  include  architecture,  control  logic,  data  structures, 
input/output  formats,  interface  design  descriptions,  and  algorithms. 

Software  Implementation  Board  (SIB) -Organization  at  Martin  Marietta  responsible  for  review  of  changes 
to  AWS  computer  programs  and  the  AWS  MK  7  element-to-element  interfaces  for  development  systems. 
Copies  of  all  AWS  CPCRs  and  ICRs  intended  for  resolution  by  the  SIB  are  sent  to  the  CRB  to  provide 
an  insight  into  development  activities  and  to  assess  for  applicability  to  in-service  programs. 

Software  Trouble  Report  (STR)  -  Mechanism  for  reporting  errors  or  problems  to  be  fixed  or  suggested 
improvements  (enhancements)  in  computer  programs.  Equivalent  to  CPCR  for  AEGIS. 

Source  Code  Analyzer  -  A  computer  program  used  to  provide  source  language  or  execution  frequency 
statistics  at  the  program  or  source-statement  level  to  assist  in  performance  evaluation  and  determination 
of  test  case  coverage. 
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Specification  -  A  document  clearly  and  accurately  describing  the  essential  technical  requirements  for  any 
component;  the  document  is  written  to  a  standard  such  as  DOD-STD-1679A. 

Specification  Change  (SC)  -  Proposed  modification  or  addition  to  an  AWS  or  ACS  tactical  or  simulation 
requirements  document.  An  SC  undergoes  an  approval  process  before  issuance  in  an  SCN. 

Specification  Change  Notice  (SCN)  -  Document  for  transmitting  and  recording  a  specification  change 
under  MIL-STD-490A.  An  SCN  may  incorporate  one  or  more  authorized  SCs.  New  specifications  do 
not  require  an  SCN  cover. 

Specification  Language  File  -  A  file  containing  statement  blocks  that  accurately  identify  the  contents  of 
the  user-defined  tables  (UDT)  that  are  used  by  ATES.  The  SYSBLD  user  also  applies  the  specification 
language  to  the  definition  of  user  application  modules  that  are  built  based  on  information  provided  by 
REL  files  and  subsequently  incorporated  into  the  target  load  file  (TLF). 

Specification  Tree  -  A  diagram  that  depicts  all  of  the  specifications  for  a  given  system  and  shows  their 
relationships  to  one  another. 

Support  Programs  -  (1)  All  programs  used  in  the  development  and  maintenance  of  the  delivered 
operational  programs  and  test/maintenance  programs.  Includes  (a)  compilers,  assemblers,  emulators, 
builders,  and  loaders  required  to  generate  machine  code  and  to  combine  subprograms  or  components 
into  a  complete  computer  program;  (b)  debugging  programs;  (c)  stimulation  and  simulation  programs 
used  in  operator  training  sites;  (d)  data  abstraction  and  reduction  programs  applicable  to  operational 
programs;  (e)  test  programs  used  in  development  of  operational  programs;  (f)  programs  used  for 
management  control,  configuration  management,  or  document  generation  and  control  development.  (2) 
A  computer  program  that  facilitates  the  design,  development,  testing,  analysis,  evaluation,  or  operation 
of  other  computer  programs.  (3)  Development  tools  used  by  project  personnel  for  computer  program 
design,  debugging,  testing  verification,  and  management. 

System  Design  Review  Team  (SRT)  -  A  team  designated  by  the  Combat  Systems  Engineer 
(PMS400B3)  to  support  the  Design  Review  Process. 

System  Tape  Builder  Utility  (SYSBLD/7.  SYSBLD/43.  SYSBLD/44)  -  System  generation  function  for  the 
AEGIS  tactical  system  that  executes  in  the  VAXA/MS  time-sharing  system  environment  to  build  tactical 
program  tapes/disks. 

Svstem/Seament  Specification  (Type  A)  -  Specification  prepared  to  practices  set  forth  in  military  standard 
MIL-STD-490A.  It  states  the  technical  and  mission  requirements  for  a  system/segment  as  an  entity, 
allocates  requirements  to  functional  areas,  documents  design  constraints,  and  defines  the  interfaces 
between  or  among  the  functional  areas.  There  is  a  Type  A  specification  for  the  AEGIS  Combat  System 
(ACS)  and  a  Type  A  specification  for  the  AEGIS  Weapon  System  (AWS);  both  are  maintained  by 
PMS400B. 

Tactical  Utility  Function  (TUF)  -  An  operating  system  residing  on  the  AN/UYK-43  and  providing  the  same 
functions  as  the  AEGIS  Tactical  Utility  System.  See  ATUS. 

Tape  Label  Description  Form  -  A  form  containing  program  name,  baseline,  version,  originating  element, 
and,  if  required,  a  QA  stamp  denoting  QA  control  is  affixed.  It  is  used  for  tracking  purposes  in  the 
AEGIS  Tape  Library. 

Tape  Listing  -  A  directory  listing  of  all  files  located  on  a  specific  tape. 

Test  Observation  Report  (TOR)  -  The  vehicle  to  document  initial  apparent  problems  observed  during 
System  Test  events.  These  initial  observations  may  also  include  questions  concerning  computer 
program  operations,  interfaces,  or  specifications. 
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Tool  (Software  Tool)  -  A  computer  program  used  to  help  develop,  test,  analyze,  or  maintain  another 
computer  program  or  its  documentation;  e.g.,  compiler,  test  tool. 

Trade-off  -  A  balancing  of  factors  all  of  which  are  not  attainable  at  the  same  time. 

Ultra  16  Assembly  Language  -  Language  used  for  16-bit  AN/UYK-44. 

Unit  -  A  unit  is  normally  a  CMS-2  procedure  (or  other  programming  language  equivalent).  However,  in 
some  cases,  a  unit  may  be  defined  as  a  small  number  of  procedures  due  to  the  way  functions  are 
allocated. 

Update  -  A  quick  fix  to  a  computer  program  that  will  solve  a  severe  operational  ship  problem.  The 
solution  is  in  patch  form  and  installed  shortly  after  the  ship  reported  the  problem. 

Upgrade  -  A  significant  increase  in  a  ship’s  baseline  functional  and  operational  capability.  Changes  may 
be  made  to  combat  system  operating  spaces,  equipment,  weapons,  and  computer  programs. 

User  Library  -  Any  non-QA/Element  Controlled  Library  is  considered  to  be  a  user  library.  It  is  a  VAX- 
based  library  established  for  tracking  changes  to  computer  programs  made  by  individual  programmers. 
A  User  Library  may  be  under  the  control  of  an  individual  programmer,  or  more  frequently,  under  the 
control  of  the  element. 

Vu-Graph  -  A  coined  word  covering  a  wide  variety  of  documentation,  usually  formatted  in  abbreviated 
style  as  for  presentation  as  a  visual  aid  and  not  under  configuration  control. 

Weapons  Control  System  (WCS)  -  As  an  element  of  the  AEGIS  Weapon  System,  performs  target 
engagement  scheduling  and/or  weapon  control  functions  for  Standard  Missile,  Harpoon,  5-inch,  54-caliber 
guns,  and  Phalanx.  Control  is  also  provided  for  ASW  aircraft,  LAMPS  helicopters,  and  air  interceptors. 

White  Paper  -  A  detailed  or  authoritative  report  stating  a  position  and  released  at  the  Element  (or 
equivalent)  level,  not  under  configuration  control. 

Work  Order  -  A  form  containing  specific  step-by-step  instructions  on  how  to  perform  a  particular  task. 
It  contains  an  area  for  tracking  information  needed  to  compile  a  complete  audit  trail  of  tasks  performed. 
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Project  Definition 


ACS  Specification  Change  (SC)  Lists 
AWS  SC  Lists 

ACSIS  Interface  Message  Specification  (IMS)  Change 
Request  (AlCR)  Lists 

The  single  control  event  for  this  phase  is  the  Project  Commitment  Review  (PCR), 
whose  purposes  are  to  assess  completeness  of  project  scope  and  resources  and  to 
obtain  PMS400  commitment. 

TABLE  11-1.  MATRIX  OF  PROCESSES  IN  THE  PROJECT  DEFINITION  PHASE 


PROCESS 

AND  THEIR  CONSTITUENT  ACTIVITIES 

ACTIVITY 

NUMBER 

TITLE 

DATE 

Develop  Proposed  Baseline 

1.1. 1.1 

initiate  Baseline  Discussions 

31  Aug  93 

Definition 

1.1. 1.2 

1.1.1.3 

Develop  Candidate  Baseline  Definition  List 

Review  Proposed  Baseline  Definition  With  Program 

31  Aug  93 

. 

Office 

31  Aug  93 

1.1. 1.4 

Outline  Baseline  Strategy 

31  Aug  93 

Obtain  Program  Office 

1.1. 2.1 

Baseline  Definition  and  Strategy  Correlation 

31  Aug  93 

Concept  Approval 

1.1. 2.2 

Approve  Baseline  Continuation 

31  Aug  93 

1.1. 2.3 

Notify  PMS400B  and  Terminate  Baseline 

31  Aug  93 

1.1. 2.4 

Identify  Baseline  Candidates 

31  Aug  93 

Develop  Baseline 

1. 1.3.1 

Conduct  System  Engineering  Studies 

31  Aug  93 

Candidate  Definition 

1.1. 3.2 

Select/Define  Baseline  Candidates 

31  Aug  93 

1.1. 3.3 

Prepare  Draft  Preliminary  Baseline  Management  Plan 

31  Aug  93 

1.1.3.3A 

1  Review  Draft  Preliminary  Baseline  Management  Plan  | 

27  Mar  95 

1.1. 3.4 

Review  Preliminary  Baseline  Definition 

31  Aug  93 

1.1. 3.5 

Review  Support  Activity  Plans 

31  Aug  93 

1.1. 3.6 

Assess  AEGIS  Combat  System  and  Ship  Impacts 

31  Aug  93 

Develop  Scope,  Schedule, 

Resource,  and  Risk 

1.1 .4.1 

Evaluate  Organization  Impact 

31  Aug  S3 

Estimates 

1.1. 4.2 

Develop  Preliminary  Scope,  Schedule,  Resource,  and 
Risk  Estimates 

29  Ju!  94 

1.1. 4.3 

Coordinate  Organization  Estimates 

29  Jul  94 

1.1. 4 .4 

Assess  Baseline  Workload  Impact 

31  Aug  93 

1.1 .4.5 

Review  Recommended  Baseline  Definition 

31  Aug  93 

1.1. 4.6 

Prepare  Baseline  Definition  Presentation 

31  Aug  93 

1.1. 4.7 

Present  Baseline  Definition  to  NSWCDD  Organizations 

31  Aug  93 

1.1. 4.8 

Update  Scope,  Schedule,  Resource,  and  Risk 
Estimates 

29  Jut  94 

Obtain  NSWCDD  Project 

1.1. 4.9 

Update  Draft  Preliminary  Baseline  Management  Plan 

29  Jul  94 

Final  Approval 

1.1.5.1 

Conduct  Baseline  Program  Review 

29  Jul  94 

1.1 .5.2 

Accept  Preliminary  Baseline  Management  Plan 

29  Jul  94 

1.1 .5.3 

Prepare  PCR  Presentation  for  PMS400B 

29  Jul  94 

1.1. 5.4 

Conduct  PCR  Presentation  Dry  Run 

31  Aug  93 

1.1. 5.5 

Update  PCR  Presentation 

31  Aug  93 

1.1. 5.6 

Approve  PCR  Presentation 

31  Aug  93 

Obtain  PMS400B  Project 

Authorization 

1.1 .6.1 

Conduct  PCR 

31  Aug  93 

1.1 .6.2 

Update  Baseline  Definition  Per  PMS400B  Direction 

31  Aug  93 

1.1. 6.3 

Authorization  to  Proceed  to  System  Definition 

31  Aug  93 
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Project  Definition  NSWCDD/MP-93/85 

Activity:  PD-1.1.3.3A 

REVIEW  DRAFT  PRELIMINARY  BASELINE  MANAGEMENT  PLAN 

The  draft  preliminary  baseline  management  plan  is  reviewed  prior  to  being 
released  by  Baseline  Management.  The  review  team  normally  includes  only  one 
representative  from  each  of  the  following  organizations;  Baseline  Management,  System 
Engineering,  System  Test  and  Integration,  and  an  Element  representative.  Baseline 
Management  requests  support  from  the  relevant  organizations  to  support  the  review. 
The  review  ensures  that  the  draft  preliminary  baseline  management  plan  is  ready  for 
review  for  concurrence  by  organizations  affected  by  the  documented  plans.  Results 
of  the  review  are  documented  in  the  baseline  development  folder  maintained  by 
Baseline  Management.  Corrective  action  is  taken  if  warranted. 

RESPONSIBLE  ORGANIZATION:  Baseline  Management 

SUPPORTING  ORGANIZATION:  System  Engineering 

ST&I 

Elements 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 
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Element  Definition 


Activities,  Products,  and  Control  Event 

Each  of  these  processes  consists  of  a  number  of  activities.  Table  1-3  is  a  matrix 
of  the  processes  and  their  constituent  activities. 

The  key  products  of  this  phase,  as  shown  in  the  process  model  in  Part  I,  are 

PIDS  SCs 

Preliminary  ICRs 

Preliminary  PPS  SCs 

Updated  Element  Development  Plan 

Simulator  Requirements 

PDR  Presentation 


Other  products  expected  to  result  from  conduct  of  the  activities  are  listed  below:^ 

Schedules 
Resource  Allocation 
Patch  Conversion  Plan 
Element  Performance  Disclosure 
Development  Tools  Definition 
Analysis  Tools 
Element  Support  Tools 
CASE  Tools 

Element  Test  Concept  Definition 
Identified  List  of  ACTS  and  CAST  Lessons 
Allocated  CPCR  List 

Man/Machine  Interface  Requirements  Definition 
Data  Analysis  Requirements  Definition 
User  Documentation  Plan 
Crew  Training  Impact  Report 
Baseline  Development  Folders 

The  single  control  event  for  this  phase  is  the  Preliminary  Design  Review,  whose 
purposes  are  to  review  validity  and  completeness  of  the  allocated  requirements  as 
defined  in  the  PIDSs,  PPSs,  and  IDSs;  apprise  PMS400  of  progress  and  plans;  and 
obtain  PMS400  authorization  to  proceed. 


^In  the  event  of  a  discrepancy  between  this  list  and  the  details  shown  in  the  process  flows  and  activities  that  follow,  the  activities 
and  flows  should  be  followed. 
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TABLE  1-3.  MATRIX  OF  PROCESSES  IN  THE  ELEMENT  DEFINITION  PHASE 

AND  THEIR  CONSTITUENT  ACTIVITIES 


PROCESS 

ACTIVITY 

NUMBER 

TITLE 

DATE 

Conduct  Element  Analysis 

1.3.1.1 

Define  Required  PPS  SCs/ICRs 

29  Jul  94 

and  Define  PPS  SCs  and 

1.3.1. 2 

Perform  Requirements  Analysis 

29  Jul  94 

ICRs 

Prepare  and  Review 

1. 3.2.1 

Prepare  Preliminary  ICRs 

18  Nov  93 

Preliminary  ICRs 

1. 3.2.2 

Conduct  Side  A  ECCB  Review  and  Approval  of 

Preliminary  ICRs 

18  Nov  93 

1. 3.2.3 

Conduct  Side  B  ECCB  Review  and  Approval  of 

Preliminary  ICRs 

18  Nov  93 

1. 3.2.4 

Conduct  NSWCDD  MK7  ICWG  Evaluation  of 

Preliminary  ICRs 

18  Nov  93 

1. 3.2.5 

Conduct  AWS  CRB  Preliminary  ICR  Processing 

18  Nov  93 

1. 3.2.6 

Present  Non  MK7  Preliminary  ICRs  for  Non  MK7 

ICWG  Review  and  Approval 

18  Nov  93 

Prepare  and  Review 

1. 3.3.1 

Prepare  Preliminary  PPS  SCs 

29  Jul  94 

Preliminary  PPS  SCs 

1.3.3.1A 

Inspect  Preliminary  PPS  SCs 

29  Jul  94 

1. 3.3.2 

Conduct  ECCB  Review  and  Approval  of  Preliminary 

PPS  SCs 

18  Nov  93 

1. 3.3.3 

Conduct  AWS  CRB  Preliminary  PPS  SC  Processing 

18  Nov  93 

Update  Element 

1. 3.4.1 

Update  Element  Development  Plans 

18  Nov  93 

Development  Plans  and 

1. 3.4.1  A 

1  Review  Element  Development  Plans  | 

27  Mar  95 

Support  Program 

1. 3.4.2 

Update  Simulator  Requirements 

18  Nov  93 

Requirements 

1. 3.4.3 

Develop  Element  Test  Concept 

18  Nov  93 

1. 3.4.4 

Initiate  System  Test  Planning 

18  Nov  93 

1. 3.4.5 

Update  Baseline  Contents 

18  Nov  93 

Develop  and  Review  PDR 

1. 3.5.1 

Prepare  PDR  Data  Package 

18  Nov  93 

Data  Package 

1. 3.5.2 

Distribute  PDR  Data  Package  for 

Review 

18  Nov  93 

1. 3.5.3 

Conduct  PDR  Data  Package  Review 

18  Nov  93 

1. 3.5.4 

Support  ERT  Review  of  PDR  Data  Package 

Comments 

18  Nov  93 

1. 3.5.5 

Support  SRT  Review  of  ERT  Comments  on  PDR  Data 

Package 

29  Jul  94 

Prepare  PDR  Presentation 

1. 3.6.1 

Prepare  Element  Portion  of  PDR  Presentation 

18  Nov  93 

and  Conduct  PDR 

1. 3.6.2 

Prepare  System  Engineering  Portion  of  PDR 

Presentation 

18  Nov  93 

1. 3.6.3 

Prepare  Baseline  Management  Portion  of  PDR 

Presentation 

18  Nov  93 

1. 3.6.4 

Conduct  Management  Review  of  PDR 

Presentation 

18  Nov  93 

1. 3.6.5 

Conduct  PDR 

18  Nov  93 

1. 3.6.6 

Update  PDR  Data  Package  Per  PMS400B 

Direction 

18  Nov  93 

Approve  and  Distribute 

1. 3.7.1 

Process  and  Distribute  IDS  SCNs  and  New  IDSs 

18  Nov  93 

SCNs  and  New 

1. 3.7.2 

Obtain  Element  Approval  of  IDS  SCNs 

18  Nov  93 

Specifications 

1. 3.7.3 

Obtain  System  Engineering  Approval  of  IDS 

SCNs 

18  Nov  93 

1. 3.7.4 

Prepare  PPS  SCNs 

18  Nov  93 

1. 3.7.5 

Obtain  Approval  of  PPS  SCNs 

18  Nov  93 

1. 3.7.6 

Distribute  PPS  and  MK7  IDS  SCNs 

18  Nov  93 
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The  Conduct  Element  Analysis  and  Define  PPS  SCs  and  ICRs  Process  is 
comprised  of  two  activities  as  described  below.  Diagram  1.3.1  (Page  II-3-9)  is  a 
data  flow  diagram  of  the  process  and  its  constituent  activities. 

Activity:  ED-1.3.1.1 

DEFINE  REQUIRED  PPS  SCs  and  ICRs 

The  Element  leader  and  engineers  consider  the  AWS  and  ACS  SCs,  the  preliminary 
ICRs  and  IDSs  developed  in  the  System  Definition  Phase,  the  PIDS  SCs,  fleet 
requests,  lessons  learned,  known  design  shortcomings,  non-Mk  7  modifications,  and 
the  baseline  management  plan;  they  begin  to  specify  the  functional  design  and  compile 
a  definition  of  the  required  PPS  SCs  and  ICRs.  Finally,  the  engineers  make  a 
determination  about  the  patches  to  be  converted  to  source  code  and  allocate  them  to 
the  builds.  They  document  these  components  in  the  Element  development  plans.  An 
example  of  the  data  considered  for  establishing  the  baseline  definition  is  the 
Government  Electronic  Systems-approved  forward-fit  PPS  SCs  and  the  PMS400B- 
approved  ICRs.  Element  leaders  then  update  the  baseline  definition  list  that  contains 
the  SCs,  ICRs,  and  CPCRs  planned  for  incorporation  and  the  Element  development 
schedule.  They  coordinate  the  schedule  with  Baseline  Management. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 


APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

Baseline  Management 
AWS  CRB  CM 
System  Engineering 
Fleet  Support 

None 

DM  1-002 


Activity:  ED-1.3.1.2 

PERFORM  REQUIREMENTS  ANALYSIS 

Element  engineers  perform  the  required  analysis  to  document  the  requirements  in 
preliminary  SCs  at  the  PPS  level  and  identify  the  ICRs  that  are  required  at  the  IDS 
level.  System  changes  that  affect  multiple  Elements  are  specified  in  multi-element 
working  groups  initiated  and  coordinated  by  System  Engineering.  If  changes  are 
required  to  the  PIDS  SCs  due  to  the  preliminary  PPS  SCs  and  ICRs,  the  changes  are 
made  and  the  previous  change  control  cycle  is  repeated.  The  analysis  includes  an 
evaluation  of  the  proposed  changes  and  identification  of  data  analysis  requirements. 
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I  The  Elements  develop  and  document  design  goals  that  form  the  basic  guidance  for 
I  computer  program  designers  to  make  appropriate  choices  in  deciding  among 
I  alternatives  as  they  implement  allocated  requirements.  Such  goals  should  include  one 
I  or  more  of  the  following  (including  specified  priorities  when  multiple  goals  are  specified): 

I  -  Resource  conservation  (minimizing  impact  on  core,  time  utilization,  or  interface 
I  impact) 

I  -  Efficiency  (i.e.,  the  resources  required  by  a  program;  each  of  the  following 

I  resources  must  be  considered:  cpu,  memory,  online  storage,  I/O  and  human 

I  development  effort) 

I  -  Maintainability  (i.e.,  the  effort  required  to  locate  and  correct  an  error) 

I  -  Flexibility  (i.e.,  the  effort  required  to  modify  an  operational  program) 

I  -  Reusability  (i.e.,  the  extent  to  which  parts  of  a  program  can  be  reused  in  other 

I  applications) 

For  new  requirements  that  cross  several  Elements  and  require  modeling  and 
computer  simulation.  System  Engineering  coordinates  the  analysis/modeling/simulation 
efforts  between  the  impacted  elements. 

The  requirements  analysis  data  includes  evidence  that  the  problem  impacts  are  well 
understood.  Typical  analysis  products  may  include: 

(1)  Models  of  algorithms 

(2)  Models  of  data  or  user  interface  design 

(3)  Control  flow  model  of  change 

(4)  Evaluation  of  model  performance 

(5)  Preliminary  impact  assessment  -  schedule,  cost,  time,  core,  etc. 

(6)  An  understanding  of  the  domain  of  change  (The  parts  of  the  system  that  change 
should  be  documented  within  a  boundary  of  system  components  that  do  not 
change.  This  should  adequately  address  logical  structure,  data  flow,  and  control 
flow  at  the  PPS  level.) 

(7)  Presentation  of  results  documented  in  reports,  graphs,  white  papers,  etc. 

These  inputs  are  compiled  in  the  Element  functional  development  folders.  The  Element 
leader  uses  the  results  of  the  requirements  analysis  to  refine  the  preliminary  SC  list  for 
input  to  Baseline  Management. 

PERFORMER: 

SUPPORTING  ORGANIZATION: 


APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

Baseline  Management 
System  Engineering 
AEGIS  Ships 

None 

None 
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The  Prepare  and  Review  Preliminary  ICRs  Process  is  comprised  of  six  activities 
as  described  below.  Diagram  1.3.2  (Page  II-3-15)  is  a  data  flow  diagram  of  the 
process  and  its  constituent  activities. 

Activity:  ED-1.3.2.1 

PREPARE  PRELIMINARY  ICRs 

During  this  activity,  the  detailed  message  contents  are  identified  and  sections  3  and 
8  of  the  IDS  are  completed.  Element  engineers,  after  reviewing  the  A-level  and  B-1  level 
SCs,  preliminary  ICRs  from  the  System  Definition  Phase,  and  preliminary  PPS  SCs;  then 
develop  and  document  message  content.  A  preliminary  NSWCDD  Mk  7  ICWG  is  held  to 
identify  the  Element  (side  A)  that  is  primarily  responsible  for  generating  the  new  ICRs. 
The  side  A  Element  prepares  the  ICR. 

Formal  inspections  are  conducted  using  the  PPS  Standard  of  Excellence  Checklist  and 
in  accordance  with  approved  inspection  procedures. 

The  ICRs  may  be  internal  to  the  AWS,  meaning  the  interface  is  a  Mk  7  Element  to 
another  Mk  7  Element  or  external  to  the  AWS,  meaning  a  Mk  7  Element  to  a  non-Mk  7 
Element.  Sometimes  side  A  may  be  the  non-Mk  7  Element  and  the  interface  is  to  a  Mk 
7  Element. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

System  Engineering 
None 

NSWCDD  AEGIS  (Preliminary)  Standard  for 
Software  Engineering  Inspections 
AEGIS  Instruction  4857 


Activity:  ED-1.3.2.2 

CONDUCT  SIDE  A  ECCB  REVIEW  AND  APPROVAL  OF  PRELIMINARY  ICRs 

Side  A  ECCB,  in  consultation  with  the  Element  engineers,  reviews  the  preliminary 
ICRs.  Their  review  ensures  that  interface  requirements  are  complete,  are  correct,  and 
conform  to  protocol  agreements;  assesses  the  impact  on  PPS  requirements;  and  ensures 
that  the  preliminary  PPS  SCs  are  consistent  with  the  new  ICRs.  They  evaluate  the  impact 
of  the  change  on  the  Element  and  its  resources.  If  the  Element  development  schedule 
is  impacted,  the  Element  leader  negotiates  any  changes  with  Baseline  Management. 
Upon  completion  of  the  side  A  technical  review,  the  side  A  Element’s  ECCB  approves  or 
disapproves  the  ICR.  If  the  ICR  is  disapproved,  it  may  be  sent  back  to  the  Element 
engineer  for  revision,  or  a  meeting  with  the  other  Element  involved  may  be  required  to 
resolve  issues.  If  the  ICR  is  approved,  the  ECCB  signs  the  ICR  and  the  side  A  Element. 


11-3-11 


27  March  1995 


Element  Definition 


NSWCDD/MP-93/8S 


the  ICR  and  the  side  A  Element  submits  the  preliminary  ICR  to  the  AWS  CRB  CM. 
The  Elements  update  the  functional  development  folders  with  the  preliminary  ICRs. 
AWS  CRB  CM  logs  the  preliminary  ICRs  into  ACCESS,  assigns  log  numbers  to  them, 
and  coordinates  with  side  B  for  Element  approval. 


PERFORMER; 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


ECCB 

AWS  CRB  CM 

None 

None 


Activity:  ED-1.3.2.3 

CONDUCT  SIDE  B  ECCB  REVIEW  AND  APPROVAL  OF  PRELIMINARY  ICRs 


Upon  receipt  of  a  preliminary  ICR  from  the  AWS  CRB  CM,  side  B  Element  ECCB 
evaluates  the  ICR  with  other  supporting  change  requests,  i.e.,  SCs,  ICRs,  CPCRs,  and 
FLCRs.  They  evaluate  the  impact  of  the  change  on  the  Element  and  its  personnel 
resources.  If  the  Element  development  schedule  is  impacted,  the  Element  leader 
negotiates  any  changes  with  Baseline  Management.  Upon  completion  of  side  B’s 
review  and  ECCB  approval,  the  ICR  is  fonwarded,  via  the  AWS  CRB  CM,  to  System 
Engineering  for  coordination  of  the  NSWCDD  MK  7  ICWG  review. 

If  side  B  disapproves,  the  ICR  issues  are  forwarded  to  System  Engineering  for 
technical  resolution  at  the  NSWCDD  MK  7  ICWG.  The  ICR  is  returned  to  side  A,  via 
AWS  CRB  CM,  for  revision  based  on  the  results  of  the  IWCG. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


ECCB 

AWS  CRB  CM 

None 

DMI-002 


Activity:  ED-1.3.2.4 

CONDUCT  NSWCDD  MK  7  ICWG  EVALUATION  OF  PRELIMINARY  ICRs 

NSWCDD  MK  7  ICWG,  chaired  by  System  Engineering,  with  support  from  the 
side  A  and  side  B  Elements,  evaluates  the  preliminary  ICRs  to  ensure  they  fulfill  the 
new  system  requirements  and  to  identify  any  conflicts.  They  work  with  the  side  A  and 
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The  Prepare  and  Review  Preliminary  PPS  SCs  Process  is  comprised  of  four 
activities  as  described  below.  Diagram  1.3.3  (Page  II-3-19)  is  a  data  flow  diagram 
of  the  process  and  its  constituent  activities. 

Activity:  ED-1.3.3.1 

PREPARE  PRELIMINARY  PPS  SCs 

The  Element  engineers  consider  the  high-level  SCs,  preliminary  ICRs,  and 
Element  analysis  or  study  results  to  develop  new  algorithms  and  preliminary  PPS 
requirements.  Element  engineers  meet  to  review  and  resolve  issues  associated  with 
the  requirements.  Additionally,  Element  engineers  evaluate  Element  analysis 
programs  and  models  for  Impact  and  plan  for  upgrades  of  those  programs  to 
precede  tactical  program  development.  IDSs  and  ICRs  are  evaluated  to  determine 
if  further  changes  are  required.  Element  models  or  analysis  tools  may  be  updated 
to  assist  in  requirements  decisions.  The  responsible  engineers  record  the 
requirements  in  preliminary  PPS  SCs  and  prepare  required  FLCRs. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Activity:  ED-1 .3.3.1  A 
INSPECT  PRELIMINARY  PPS  SCs 


Elements 
None 
None 
DM  1-002 

NSWCDD  AEGIS  (Preliminary) 
Standard  for  Software  Engineering 
Inspections 

AEGIS  Instruction  4857 


The  respective  Element  conducts  an  inspection  of  the  preliminary  PPS  SCs 
according  to  approved  standards  and  using  approved  checklists.  The  inspection 
verifies  that  the  form  and  described  functions  are  complete,  consistent  (internally  as 
well  as  with  other  documents  such  as  IDSs),  and  accurate.  The  inspection  also 
focuses  on  the  appropriateness  of  the  content  of  the  information. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

NSWCDD  Organizations 
None 

NSWCDD  AEGIS  (Preliminary) 
Standard  for  Software  Engineering 
Inspections 

AEGIS  Instruction  4857 
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Activity:  ED-1.3.3.2 

CONDUCT  ECCB  REVIEW  AND  APPROVAL  OF  PRELIMINARY  PPS  SCs 

The  ECCB,  in  conjunction  with  the  Element  engineers,  reviews  the  preliminary 
PPS  SCs.  They  evaluate  the  impact  of  the  change  on  the  Element  and  its  resources. 
The  ECCB  assesses  both  the  technical  accuracy  of  the  proposed  change  as  well  as 
whether  the  proposed  change  can  be  executed.  If  the  Element  development  schedule 
is  impacted,  the  Element  leader  negotiates  any  changes  with  Baseline  Management. 
The  ECCB  approves  (or  disapproves)  the  PPS  SCs  when  the  reviews  are  complete. 
The  Elements  update  the  functional  development  folder  with  the  preliminary  PPS  SCs. 
The  ECCB  then  submits  the  PPS  SCs  to  AWS  CRB  CM. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 

APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


ECCB 

Baseline  Management 

AWS  CRB  CM 

None 

DMI-001 

DMI-002 


Activity:  ED-1.3.3.3 

CONDUCT  AWS  CRB  PRELIMINARY  PPS  SC  PROCESSING 

AWS  CRB  CM  ensures  that  the  PPS  SCs  have  been  reviewed  and  approved  by 
the  ECCBs  and  that  any  associated  ICRs,  SCs,  FLCRs,  and  CPCRs  are  part  of  the 
review  package.  (If  the  SCs  are  distributed  with  sufficient  lead  time  before  the  AWS 
CRB  meeting.  Documentation  Management  inserts  copies  of  the  SCs  into  the  dynamic 
working  copies  of  the  affected  specifications,  which  are  available  for  review  in  the 
AEGIS  Data  Center.)  The  AWS  CRB  then  approves  (or  disapproves)  and  signs  off  on 
the  SCs,  and  the  AWS  CRB  CM  updates  the  status  of  the  PPS  SCs  in  the  ACCESS 
database.  Documentation  Management  incorporates  those  approved  SCs  that  were 
not  previously  placed  in  the  dynamic  working  copies  and  makes  necessary  adjustments 
to  those  SCs  that  were  placed  in  the  dynamic  working  copies  prior  to  the  AWS  CRB. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 


APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


AWS  CRB 

Elements 

AWS  CRB  CM 

Documentation  Management 

None 

DMI-001 
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The  Update  Element  Development  Plans  and  Support  Program 
Requirements  Process  is  comprised  of  six  activities  as  described  below. 
Diagram  1.3.4  (Page  II-3-25)  is  a  data  flow  diagram  of  the  process  and  its 
constituent  activities. 

Activity:  ED-1.3.4.1 

UPDATE  ELEMENT  DEVELOPMENT  PLANS 

Based  on  the  ECCB  requirements  analysis  and  impact  assessment,  the  PPS 
SCs,  the  ICRs,  and  the  PIDSs  changes,  each  Element  updates  its  Element 
development  plan.  The  plans  include  a  definition  of  the  build  functionality:  a  list  of 
the  approved  PPS  SCs,  ICRs,  FLCRs,  and  allocated  CPCRs;  a  description  of 
resource  impacts;  element  development  schedules;  and  a  description  of  and  plan  for 
managing  identified  risks.  The  Element  leader  forwards  the  updated  Element 
development  schedule  to  Baseline  Management.  Any  schedule  changes  that  impact 
the  baseline  schedule  are  approved  by  Baseline  Management. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION;  Baseline  Management 

System  Engineering 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION;  None 


Activity:  ED-1 .3.4.1  A 

REVIEW  ELEMENT  DEVELOPMENT  PLANS 

Each  Element  reviews  their  Element  development  plan.  The  review  verifies  that 
the  form  and  described  functions  are  completed,  consistent  (internally  as  well  as  with 
other  documents  such  as  the  baseline  management  plan),  and  accurate.  The  review 
also  focuses  on  the  appropriateness  of  the  content  of  the  information. 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION;  None 


11-3-21 


27  March  1995 


Element  Definition 


NSWCDD/MP-93/85 


Activity;  ED-1.3.4.2 


UPDATE  SIMULATOR  REQUIREMENTS 


Based  on  preliminary  PPS  SCs  and  ICRs  and  Element  development  plans,  AIS, 
Elements,  System  Engineering,  ST&E,  and  the  ATC  engineers  perform  the  required 
analysis  to  update  the  specific  simulator  performance  requirements  for  the  ACSIS 
systems  and  ORTSIS,  if  applicable.  AIS  engineers  coordinate  the  defined 
requirements.  The  ATC,  in  consultation  with  Systems  Simulation,  develops  training 
requirements.  Any  schedule  changes  that  impact  the  baseline  schedule  are  approved 
by  Baseline  Management. 


PERFORMER; 

SUPPORTING  ORGANIZATION: 

APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION; 


NSWCDD  Organizations 
ATC 

Baseline  Management 

None 

None 


Activity:  ED-1.3.4.3 

DEVELOP  ELEMENT  TEST  CONCEPT 

Based  on  performance  and  interface  requirements.  Elements  review  and  analyze 
existing  test  plans  and  procedures  for  impact  and  identify  required  changes.  Element 
test  concepts  are  developed.  Test  concepts  include  (1)  tests  to  be  changed  and  their 
description,  (2)  new  tests  and  their  descriptions,  and  (3)  selected  regression  tests  to 
be  conducted.  Upon  identification  of  the  element  test  concept,  each  Element  develops 
a  schedule  for  test  development  and  conduct.  The  products  of  this  activity  are  used 
to  update  the  element  development  plan. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

System  Engineering 

None 

None 
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4.  HIGH-LEVEL  DESIGN  PHASE 


The  High-Level  Design  Phase  is  concerned  with  the  physical  architecture  of  the  AWS 
computer  programs,  functional  allocation  of  requirements,  and  high-level  design  of  the 
computer  programs.  This  phase  includes  completing  the  specification  of  impacted 
interfaces  to  the  message,  word,  and  field  level.  This  effort  ensures  that  desired  changes 
to  the  logical  and  physical  system  can  be  accomplished  within  the  resources  (memory  and 
time)  of  each  Element. 

Each  Element  formulates  the  high-level  design  as  required  by  approved  PPS  SCs, 
ICRs,  and  CPCRs.  The  Elements  perform  a  preliminary  design  impact  analysis,  allocating 
requirements  to  modules  and  analyzing  module  interfaces.  They  select  the  appropriate 
architectural  features  and  update  the  design  documentation  and  affected  specifications. 
The  Elements  then  allocate  requirements  to  procedures,  define  any  impacts  to  procedure 
interfaces,  and  conduct  a  formal  review  of  the  high-level  design  of  all  areas  of  the  computer 
program  impacted  by  the  change. 

Following  the  review,  the  Elements  define  the  build  contents  and  build  schedule  and 
begin  to  plan  their  test  activities.  Element  engineers  analyze  test  requirements,  identify 
required  tests,  and  develop  the  Element  test  plan.  A  formal  review  of  the  Element  test  plan 
ensures  the  technical  and  management  issues  are  addressed. 

The  control  event  for  the  High-Level  Design  Phase  is  the  Critical  Design  Review 
(CDR).  In  preparation  for  this  review,  the  Elements  prepare  a  CDR  data  package 
describing  each  functional  change  and  depicting  the  traceability  of  the  change  to  the 
performance  specification.  Element  Design  Review  Teams  and  the  System  Design  Review 
Team  review  the  package,  and  their  comments  are  incorporated.  System  Engineering  also 
prepares  a  CDR  presentation  describing  system-level  functional  changes,  and  Baseline 
Management  prepares  an  updated  schedule  for  presentation  at  the  CDR. 

The  CDR  is  coordinated  by  Baseline  Management.  Each  organization  presents  its 
data  package,  and  comments  are  solicited.  Discussions  focus  on  issues;  open  items;  and 
any  significant  scope,  schedule,  and  resource  changes.  Acceptance  of  the  results  by 
PMS400B  and  the  Executive  Panel  represents  authorization  to  proceed  to  the  Build 
Implementation  Phase. 

Following  the  CDR,  the  Elements  make  any  directed  changes  to  the  design 
documentation  and  update  the  baseline  development  folders  with  the  current  information. 
Baseline  Management  then  updates  the  baseline  management  plan,  and  Documentation 
Management  prepares  and  distributes  the  updated  design  documentation. 
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There  are  six  processes  in  the  High-Level  Design  Phase  (see  Table  11-4): 

Perform  Preliminary  Design  Impact  Analysis  Process  (1.4.1) 

Develop  High-Level  Design  Process  (1.4.2) 

Plan  Development  Activities  Process  (1.4.3) 

Plan  Test  Activities  Process  (1.4.4) 

Develop  CDR  Data  Package  Process  (1.4.5) 

Conduct  CDR  Process  (1.4.6) 

Diagram  1.4  (Page  II-4-5)  is  a  depiction  of  the  High-Level  Design  Phase, 
including  its  six  processes. 

Activities,  Products,  and  Control  Event 

Each  of  these  processes  consists  of  a  number  of  activities.  Table  II-4  is  a  matrix  of 
the  processes  and  their  constituent  activities.  The  key  products  of  this  phase,  as  shown  in 
the  process  model  in  Part  I,  are: 

PPS  SCs 
ICRs 

Element  Test  Plans 
Program  Design  Documents 
CDR  Presentation 

Other  products  expected  to  result  from  conduct  of  the  activities  are  listed  below: 

Time  and  Memory  Estimates 
Data  Analysis  Definition 

The  single  control  event  for  this  phase  is  the  Critical  Design  Review  (CDR).  The 
purpose  of  the  CDR  is  to: 

Ensure  that  the  physical  architecture  and  high-level  design  satisfy  the  requirements 
Review  validity  and  completeness  of  design  documentation  and  IDSs 
Ensure  interface  working  groups'  approval  of  interface  requirements 
Apprise  PMS400  of  progress  and  obtain  authorization  to  proceed 
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TABLE  11-4.  MATRIX  OF  PROCESSES  IN  THE  HIGH-LEVEL  DESIGN  PHASE 
AND  THEIR  CONSTITUENT  ACTIVITIES 


PROCESS 


ACTIVITY 


Perform  Preliminary 
Design  Impact  Analysis 


Develop  High-Level  Design 


Plan  Development  Activities 


Plan  Test  Activities 


Develop  CDR  Data 
Package 


Conduct  CDR 


NUMBER 

TITLE 

DATE 

1. 4.1.1 

Allocate  Requirements  to  Design  Functions 

27  Mar  95 

1.4.1. 2 

Allocate  Design  Functions  to  Modules 

27  Mar  95 

1.4.1. 3 

Analyze  Module  Interfaces 

27  Mar  95 

1.4.1. 4 

Select  Architectural  Features 

27  Mar  95 

1.4.1. 5 

Develop/Update  Required  Documents 

27  Mar  95 

1. 4.2.1 

Allocate  Requirements  to  Units 

27  Mar  95 

1. 4.2.2 

Define  Unit  Interface  Impacts 

27  Mar  95 

1. 4.2.3 

Review  High-Level  Design 

27  Mar  95 

1. 4.3.1 

Define  Build  Contents 

27  Mar  95 

1. 4.3.2 

Define  Build  Schedule 

27  Mar  95 

1. 4.3.3 

Update  Planning  Documents 

27  Mar  95 

1. 4.3.4 

Review  Build  Definition  and  Schedule 

27  Mar  95 

1. 4.3.5 

Prepare  for  Code  Development 

27  Mar  95 

1. 4.4.1 

Define  Required  Element  Tests 

27  Mar  95 

1. 4.4.2 

Develop  Element  Test  Plan 

27  Mar  95 

1. 4.4.3 

Develop  System  Test  Requirements 

27  Mar  95 

1. 4.5.1 

Prepare  CDR  Data  Package 

27  Mar  95 

1. 4.5.2 

Review  CDR  Data  Package 

27  Mar  95 

1. 4.5.3 

Review  and  Categorize  CDR  Data  Package 

Comments 

27  Mar  95 

1. 4.5.4 

Review  ERT  Comment  Categories  and  Resolve 

Problems 

27  Mar  95 

1. 4.6.1 

Update  Element  CDR  Presentation 

27  Mar  95 

1. 4.6.2 

Prepare  System  Engineering 

CDR  Presentation 

27  Mar  95 

1. 4.6.3 

Prepare  Facilities  Engineering  CDR  Presentation 

27  Mar  95 

1. 4.6.4 

Review  Technical  CDR  Presentation  Material 

27  Mar  95 

1. 4.6.5 

Prepare  Baseline  Management  CDR  Presentation 

27  Mar  95 

1. 4.6.6 

Conduct  CDR  Meeting 

27  Mar  95 

1. 4.6.7 

Update  Technical  Documentation  Per  CDR  Direction 

27  Mar  95 

1. 4.6.8 

Review  and  Approve  DDCRs 

27  Mar  95 

1. 4.6.9 

Update  Management  Plans 

27  Mar  95 

1.4.6.10 

Update  Engineering  Documentation 

27  Mar  95 
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1.4.1  PERFORM  PRELIMINARY  DESIGN  IMPACT  ANALYSIS  PROCESS 

The  Perform  Preliminary  Design  Impact  Analysis  Process  is  comprised  of  five 
activities  as  described  below.  Diagram  1.4.1  (Page  11-4-11)  is  a  data  flow  diagram  of 
the  process  and  its  five  constituent  activities. 

Activity:  HLD-1 .4.1.1 

ALLOCATE  REQUIREMENTS  TO  DESIGN  FUNCTIONS 

Element  personnel  review  all  SCs  planned  for  the  current  baseline  in  conjunction 
with  the  current  design  functions  as  documented  in  the  Element  design  document.  Each 
new  or  modified  requirement  is  tentatively  associated  with  a  design  function.  Where 
substantially  new  or  extensively  modified  requirements  are  being  considered,  new  design 
functions  may  be  created.  In  some  cases,  entire  groups  of  related  requirements  may  be 
associated  with  a  new  or  existing  design  function  as  an  entity  rather  than  as  individual 
requirements.  In  addition,  the  CPCRs  which  have  the  potential  to  impact  high-level  design 
are  reviewed.  Affected  design  functions  are  evaluated  and  modified  as  required. 

Revised  estimates  for  design  function  resource  requirements  (memory,  CPU,  etc.) 
are  calculated  based  on  the  proposed  modifications.  Requirement  to  design  function 
allocations  are  adjusted  as  appropriate  to  preserve  the  viability  of  each  design  function  in 
terms  of  its  available  resources. 

The  Element  group  leader  reviews,  adjusts  as  appropriate,  and  approves  each 
modified  design  function.  Element  engineers  update  the  requirement  to  design  function 
matrix  in  the  Element  design  document  to  reflect  the  allocations  approved  by  the  Element 
group  leader.  The  abstract  for  each  impacted  design  function  is  then  updated  or  rewritten 
to  reflect  the  new  or  modified  requirement. 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.1.2 

ALLOCATE  DESIGN  FUNCTIONS  TO  MODULES 

Prior  to  beginning  the  actual  allocation.  Element  personnel  review  the  design  goals 
documented  in  the  baseline  development  folder.  These  goals,  considered  in  conjunction 
with  performance  goals  and  target  system  resource  issues,  are  translated  into  specific 
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design  attributes  or  architecture  such  as  reduced  complexity  and  increased  functional 
cohesion,  and  documented  with  the  design  goals  in  the  PDD.  Appropriate  tools  and 
methods  for  completing  the  software  implementation,  consistent  with  design  goals  and 
implementation  resource  constraints,  are  identified,  selected,  and  reflected  appropriately 
in  the  Element  development  plan. 

Each  new  or  modified  requirement  in  each  impacted  design  function  is  assigned  to 
one  of  the  modules  or  channel  programs  associated  with  the  parent  design  function.  In 
some  cases,  new  modules  may  be  created  or  existing  requirements  may  be  moved  from 
one  module  to  another  in  performing  this  function.  These  trial  allocations  are  modified  until 
the  identified  goals  and  constraints  are  best  satisfied  and  the  integrity  of  the  existing  design 


is  preserved  or  improved. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.1.3 
ANALYZE  MODULE  INTERFACES 

Data  and  control  flows  necessary  to  support  the  trial  allocations  documented  in  the 
previous  activity  are  identified  and  analyzed.  Flows  to  and  from  other  modules,  elements, 
and  external  devices  must  be  considered  and  their  impacts  assessed.  Assessments  must 
include  any  effects  on  program  characteristics  such  as  cohesion,  coupling,  complexity,  and 
CPU  and  memory  usage  as  they  pertain  to  design  goals  and  resource  constraints.  CPCRs 
that  impact  interfaces  are  included  in  the  analysis.  Flows  to  and  from  other  Elements  must 
be  negotiated  by  personnel  from  both  Elements  in  order  to  best  satisfy  the  design  goals  and 
resource  constraints  of  all  affected  Elements. 

Alternative  allocations  are  considered  in  attempts  to  satisfy  defined  goals  and 
constraints  more  effectively.  With  each  alternative,  data  and  control  flows  must  be 
redefined  and  assessments  must  be  recalculated  and  compared  to  previous  alternatives 
relative  to  design  goals  and  resource  constraints.  Details  of  the  physical  implementation 
(e.g.,  if  data  exchanges  will  occur  via  messages  or  shared  data,  or  the  mechanics  of 
module  scheduling)  are  largely  ignored  at  this  time  in  order  to  concentrate  on  issues  such 
as  functional  cohesion,  attaining  low-to-moderate  complexity,  and  desirable  coupling. 
Finally,  the  set  of  allocations  and  data  and  control  flows  which  best  satisfies  goals  and 
constraints  is  selected  and  documented  as  the  module-level  functional  design. 
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PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.1.4 

SELECT  ARCHITECTURAL  FEATURES 

Each  data  and  control  flow  identified  in  the  functional  design  is  considered  in  view 
of  the  AEGIS  architectural  features  available  to  support  it.  Based  on  design  goals  and 
resource  constraints,  one  or  more  architectural  features  are  tentatively  selected  for 
implementing  each  data  and  control  flow. 

As  these  features  are  selected,  the  module-level  requirements  allocations  can  be 
further  refined  by  assigning  requirements  to  individual  module  entrances.  As  more  and 
more  selections  are  tentatively  made,  the  criteria  for  selecting  additional  features  (e.g., 
entrance  priorities  and  preemption  levels,  shared  data  or  intermodule  messages  as 
communications  media,  input/output  mechanisms,  and  module  scheduling  techniques)  can 
be  recognized. 

When  architectural  features  for  implementing  all  aspects  of  the  functional  design 
have  been  tentatively  selected,  the  total  effect  on  performance  and  design  goals  and 
constraints  is  evaluated  and  timing  and  resource  estimates  are  updated.  All  allocations  and 
feature  selections  are  reconsidered  for  possible  improvement  in  order  to  satisfy  design 
goals  and  constraints  more  effectively.  When  Element  personnel  are  satisfied  that  goals 
and  constraints  have  been  adequately  satisfied,  the  current  decisions  are  documented  in 


the  high-level  design  document. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 
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DEVELOP/UPDATE  REQUIRED  DOCUMENTS 

Information  from  the  module  design  developed  in  the  preceding  activity  is  translated 
into  the  proper  format  and  documented  in  the  Element  design  document.  The  functional 
description  of  all  impacted  modules  is  updated  to  reflect  the  latest  changes  at  a  level  of 
detail  sufficient  to  determine  exactly  which  PPS-level  requirements  have  been  allocated  to 
which  modules.  A  depiction  of  intermodule  data  and  control  flow  is  included.  Details  on  the 
mechanisms  used  to  effect  data  transfers  and  intermodule  scheduling  are  then  added. 
Core  and  timing  estimates  are  documented  in  the  high-level  design  document  with 
supporting  rationale. 

Information  on  modified  global  data  and  new  or  changed  intermodule  messages  is 
added  to  the  Element  design  document.  Specifications  such  as  PPSs,  PIDSs,  and  IDSs 
are  updated,  as  required,  to  reflect  errors  or  changes  discovered  during  the  design 
process. 

The  Element  development  plan  is  updated  to  reflect  the  planning  and  scheduling 
details  which  emerged  during  the  preliminary  high-level  design  effort.  The  baseline 
management  plan  is  referenced  to  ensure  that  these  emerging  details  do  not  jeopardize 
previous  commitments  to  other  Elements  or  baseline  management.  Finally,  the  basic 
agenda  and  schedule  for  the  CDR  are  identified  and  Baseline  Management  prepares  the 
CDR  plan. 

PERFORMER;  Elements 

SUPPORTING  ORGANIZATION;  Documentation  Management 

Baseline  Management 

APPROVAL  REQUIRED;  None 

APPLICABLE  INSTRUCTION;  None 
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1.4.2  DEVELOP  HIGH-LEVEL  DESIGN  PROCESS 

The  Develop  High-Level  Design  Process  is  comprised  of  three  activities  as 
described  below.  Diagram  1.4.2  (Page  II-4-15)  is  a  data  flow  diagram  of  the  process 
and  its  three  constituent  activities. 

Activity:  HLD-1 .4.2.1 

ALLOCATE  REQUIREMENTS  TO  UNITS’ 

After  reviewing  design  goals,  resource  issues,  existing  module  input/output  and  unit 
design,  and  the  requirements  allocated  to  each  module,  Element  personnel  further  allocate 
requirements  to  new  or  existing  units  or  channel  programs.  As  this  allocation  occurs,  the 
impact  on  the  design  of  existing  units  is  assessed  in  terms  of  design  goals  and  resource 
constraints.  Particular  attention  is  paid  to  improving  functional  cohesion,  reducing 
complexity,  and  minimizing  coupling.  This  is  an  iterative  process  which  must  be  repeated 
until  all  design  goals  have  been  met  and  critical  resources  conserved  to  the  maximum 
extent  practical.  Appropriate  tools  and  methods  for  completing  the  software  implementation 
are  reviewed.  The  Element  development  plan  is  updated,  as  needed,  to  reflect  changes. 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.2.2 

DEFINE  UNIT  INTERFACE  IMPACTS 

Using  the  trial  allocation  from  the  preceding  activity  as  a  starting  point,  interunit  data 
and  control  flows  and  interchannel  program  data  and  control  flows  are  identified.  Impacts 
on  other  units,  data,  channel  programs,  and  AEGIS  Elements  are  identified  and  studied. 
Each  impact  is  assessed  for  adverse  effects  on  design  characteristics  such  as  cohesion, 
complexity,  coupling,  timing,  and  resource  usage.  Alternative  requirements  allocations  are 
tried,  flows  reidentified,  and  impacts  reassessed  until  design  goals  and  resource  constraints 
have  been  best  satisfied.  At  this  time,  each  unit  must  also  be  assessed  to  identify  any 
special  problems  associated  with  performing  unit  test.  Units  posing  special  problems  may 
be  redesigned  or  the  resources  to  overcome  the  special  problems  must  be  identified  and 
documented. 


A  unit  is  normally  a  CMS-2  procedure  (or,  other  programming  ianguage  equivalent).  However,  in  some  cases,  a  unit  may 
be  defined  as  a  small  number  of  procedures  due  to  the  way  functions  are  allocated. 
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When  agreement  on  an  approach  is  reached,  new  or  modified  local  data 
requirements  are  identified  and  defined,  new  core  and  timing  estimates  are  prepared,  and 
the  results  are  documented  in  the  Element  design  document.  CPCR  folders  are  also 
updated  to  reflect  allocations  or  design  information  differing  from  that  previously  shown. 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.2.3 
REVIEW  HIGH-LEVEL  DESIGN 

The  high-level  design  of  all  areas  of  the  Element  computer  program  impacted  by 
change  is  evaluated  during  formal  element-level  design  reviews.  The  activity  begins  by 
identifying  the  specific  areas  of  the  Element  computer  program  to  be  covered  by  each 
review.  Review  participants  possess  a  knowledge  of  the  affected  areas  and  an  ability  to 
understand  and  identify  improvements  to  the  proposed  changes.  Materials  used  in  support 
of  reviews  are  collected  from  information  contained  in  the  PDD,  CPCR  folders,  and  working 
papers  of  the  Element  engineers  who  performed  the  actual  design  work. 

The  high-level  design  is  reworked  and  redocumented  until  all  issues  identified  during 
the  reviews  are  resolved.  If  rework  was  significant,  follow-on  reviews  may  be  required. 
Each  applicable  CPCR  folder  is  updated  to  reflect  any  rework  resulting  from  review 
decisions. 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 
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1.4.3  PLAN  DEVELOPMENT  ACTIVITIES  PROCESS 

The  Plan  Development  Activities  Process  is  comprised  of  five  activities  as 
described  below.  Diagram  1.4.3  (Page  11-4-21)  is  a  data  flow  diagram  of  the  process 
and  its  five  constituent  activities. 


Activity:  HLD-1 .4.3.1 
DEFINE  BUILD  CONTENTS 

Element  planners  define  a  system  of  builds  using  an  iterative  process  which  begins 
by  examining  the  entire  set  of  proposed  functional  and  physical  changes,  including  CPCRs, 
and  reviewing  the  overall  goals  and  plans  for  the  baseline  upgrade.  Based  on  this  review, 
groups  of  functional  and  physical  capabilities  which  can  be  implemented  together  (detail- 
design,  code,  unit-test,  and  integration)  are  identified.  These  groups  of  capabilities  are 
allocated  to  trial  builds. 

As  the  trial  build  definitions  begin  to  emerge,  each  is  examined  for  several  key 
issues:  the  resources  required  for  its  development  and  validation,  the  complexity  of  its 
component  parts,  the  time  required  for  its  completion,  and  the  importance  of  each  of  its 
components  to  the  success  of  the  overall  baseline  upgrade.  The  trial  definitions  are  then 
adjusted  to  achieve  each  of  the  following:  an  adequate  degree  of  resource  leveling,  a 
reasonable  mixture  of  complex  and  simple  capabilities  in  each  build,  and  builds  of 
acceptable  duration.  Initial  definition  of  site  and  simulator  requirements  for  each  build  is 
specified.  Additionally,  a  determination  of  the  impact  of  the  patch  conversions  is  made. 

If  the  Element's  role  in  the  baseline  upgrade  is  small  and  simple,  it  is  possible  for  all 
capabilities  to  be  allocated  to  a  single  build. 


PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  None 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 
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DEFINE  BUILD  SCHEDULE 

The  trial  build  definitions  are  placed  in  a  sequence  based  on  any  necessary 
successor/predecessor  relationships  and  interelement  needs.  Conflicts  are  resolved  by 
adjusting  build  content.  Once  these  relationships  are  satisfied,  Element  planners  adjust  the 
sequence  to  place  high-risk  or  vitally  important  builds  early  in  the  schedule  (without 
sacrificing  any  of  the  essential  successor/predecessor  relationships).  Finally,  the  content 
of  each  build  is  analyzed  to  determine  the  site  and  labor  resources  required  to  perform  build 
integration  and  test. 

PERFORMER;  Elements 

SUPPORTING  ORGANIZATION:  Baseline  Management 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.3.3 
UPDATE  PLANNING  DOCUMENTS 

The  Element  development  plan  is  updated  to  reflect  the  build  definition  and  schedule 
prepared  during  the  previous  activities  and  to  include  schedules  for  planned  usage  of  sites 
for  required  simulators  and  site  availability.  In  addition,  the  agenda,  participants,  and 
discussion  items  for  the  CDR  are  identified  and  documented  in  the  Element  module  of  the 
CDR  plan. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  Baseline  Management 

Facilities  Engineering 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Backfit  Design  Review  Manual 
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Activity:  HLD-1 .4.3.4 

REVIEW  BUILD  DEFINITION  AND  SCHEDULE 

Upon  agreement  on  the  Element's  build  definitions  and  schedules,  a  meeting  is 
convened  by  Baseline  Management  to  provide  NSWCDD  Organizations  an  opportunity  to 
gain  insight  into  Element  plans  that  may  either  impact  them  or  that  may  appear  to  involve 
some  level  of  risk  that  is  unaccounted  for.  The  build  comments  from  this  meeting  are 
returned  to  the  Elements  for  resolution.  The  baseline  management  plan,  including 
schedule,  is  updated,  as  required.  Additionally,  Element  development  plans,  including 
schedules,  are  updated. 

PERFORMER:  Baseline  Management 

SUPPORTING  ORGANIZATION:  NSWCDD  Organizations 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.3.5 

PREPARE  FOR  CODE  DEVELOPMENT 

The  Elements  request  that  QA  establish  new  baseline  fiies.  Together  with  QA,  the 
Eiements  build  a  CMS  class  for  the  new  baseline  and  transfer  the  relevant  baseline  files  to 
the  Element  user  directory  (product  file).  QA  verifies  program  library  integrity. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

NSWCDD  Organizations 

None 

None 
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1.4.4  PLAN  TEST  ACTIVITIES  PROCESS 

The  Plan  Test  Activities  Process  is  comprised  of  three  activities  as  described 
beiow.  Diagram  1.4.4  (Page  ii-4-25)  is  a  data  flow  diagram  of  the  process  and  its 
three  constituent  activities. 


Activity:  HLD-1 .4.4.1 

DEFINE  REQUIRED  ELEMENT  TESTS 

Element  engineers  determine  requirements  to  be  included  in  Element-level  tests  by 
analyzing  test  requirements  and  computer  program  requirements.  Element  engineers  must 
consider  any  system  requirements  in  the  system  specification  documented  as  having  been 
deferred  to  Element  tests.  Element  engineers  analyze  test  plans  from  earlier  baselines  to 
determine  reusable  components  as  well  as  to  gain  insight  into  structuring  tests  and 
allocating  test  requirements  to  appropriate  tests.  Existing  tests  that  may  be  reused  may 
require  modification  or  adaptation  due  to  requirements  or  design  changes.  The  result  of 
this  activity  is  a  description  of  each  Element  test  that  is  required  to  cover  the  planned 
Element  changes  and  indications  of  which  test  may  be  reused  without  change,  reused  with 
modification,  or  used  for  insight  in  creating  new  tests.  Existing  tests  are  reviewed  to 
determine  the  changes  that  must  be  implemented  to  accommodate  planned  enhancements 
or  changes  to  the  Element. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Activity:  HLD-1 .4.4.2 
DEVELOP  ELEMENT  TEST  PLAN 

Element  personnel  define  each  test  identified  in  the  previous  activity.  The  test  plan 
developed  includes  specific  requirements  being  tested  in  each  test,  site  utilization 
information,  special  test  equipment,  and  special  test  resources  (e.g.,  data  collection,  data 
reduction,  operators,  aircraft,  and  simulators).  The  plan  documents  assumptions  which 
could  affect  the  validity  or  execution  of  the  plan.  Element  personnel  identify  all  test 
procedures  that  must  be  developed,  their  interdependencies,  and  their  schedule  for 
execution.  The  plan  describes  all  supporting  personnel  roles  and  responsibilities  required 
to  conduct  the  tests,  collect  required  data,  reduce  and  analyze  the  data,  and  produce 
reports  documenting  the  results  of  the  tests. 


Elements 

System  Engineering 

None 

QAI-017 
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PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

System  Engineering 

None 

QAI-017 


Activity:  HLD-1 .4.4.3 

DEVELOP  SYSTEM  TEST  REQUiREMENTS 

System  requirements  are  analyzed  to  determine  and  document  the  system  level 
verification  requirements.  The  system  requirements  are  translated  into  test  requirements. 
Based  upon  the  resulting  test  requirements,  required  test  support  resources  are  estimated 
(e.g.,  personnel,  facilities,  special  equipment,  services,  and  non-AWS  system  interfaces). 
Testing  issues  are  assessed  and  risks  are  evaluated  and  documented.  The  resulting  test 
requirements,  resource  estimates,  and  risk  data  are  documented  in  the  baseline 
development  folders. 

PERFORMER:  System  Engineering 

SUPPORTING  ORGANIZATION:  System  Test 

Facilities  Engineering 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 
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1.4.5  DEVELOP  CDR  DATA  PACKAGE  PROCESS 

The  Develop  CDR  Data  Package  Process  is  comprised  of  four  activities  as 
described  below.  Diagram  1.4.5  (Page  11-4-31)  is  a  data  flow  diagram  of  the  process 
and  its  four  constituent  activities. 

Activity:  HLD-1 .4.5.1 

PREPARE  CDR  DATA  PACKAGE 

Element  personnel  review  the  requirements  for  the  CDR  given  in  the  CDR  design 
review  plan.  Documentation  is  prepared  or  assembled  that  describes  each  functional 
change  or  CPCR  on  the  change  list  and  shows  the  traceability  of  each  change  back  to  the 
PPS.  Changes  can  have  an  effect  on  components  of  the  code  that  are  not  directly 
represented  in  functions  documented  in  the  computer  program  performance  specification. 
For  this  reason,  Element  personnel  identify  all  components  affected  by  changes  required 
by  the  changed  computer  program  requirements  (i.e.,  the  domain  of  change)  and  document 
the  domain  of  change  for  presentation  at  the  CDR.  Element  personnel  assemble  interface 
documentation  and  subprogram  functional  logic  documentation  for  all  changes.  The  results 
of  timing  and  memory  utilization  analysis  are  documented.  The  required  tests,  as 
documented  in  the  CDR  plan,  are  evaluated  for  test  change  impact.  The  Elements  prepare 
presentation  materials,  and  all  other  outputs  of  this  effort  are  documented  in  the  CDR  data 
package.  Documentation  Management  assembles  and  distributes  the  CDR  data  package 
within  NSWCDD. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  Documentation  Management 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.5.2 
REVIEW  CDR  DATA  PACKAGE 

System  Engineering  and  the  Elements  meet  to  review  the  CDR  data  package. 
System  Engineering  reviews  and  endorses  ail  Element  CDR  packages  to  ensure  system 
requirements  are  met.  Element  designs  are  acceptable,  and  requisite  Element  connectivity 
issues  are  addressed. 


11-4-27 


27  March  1995 


High-Level  Design 


NSWCDD/MP-93/85 


Upon  completion  of  the  review  of  the  CDR  data  package,  Element  engineers  meet  to  review 
and  respond  to  the  submitted  comments  and  prepare  for  Element  Design  Review  Team 
(ERT)  review.  The  CDR  data  package  is  updated,  and  Documentation  Management 
distributes  the  package  to  Navy  review  teams  (ERTs  and  SRT)  established  by  PMS  400. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 


APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Elements 

Baseline  Management 

System  Engineering 

Documentation  Management 

AIS 

ATC 

None 

Backfit  Design  Review  Manual 


Activity:  HLD-1 .4.5.3 

REViEW  AND  CATEGORIZE  CDR  DATA  PACKAGE  COMMENTS 

The  ERTs  are  convened  by  PMS400  Warfare  Area  Commanders  to  review  the  CDR 
data  package.  The  designated  chairman  directs  the  ERT  to  review  and  agree  to  an  action 
category  for  each  comment.  The  categories  are  A-D,  depending  on  the  difficulty  of 
resolution,  per  the  backfit  design  review  manual.  If  necessary,  the  commenting  author  is 
requested  to  provide  cornment  rationale. 

The  ERT  chairman  documents  outstanding  issues,  the  rationale  for  the 
categorization  of  the  comments,  and  any  specific  comments  deemed  necessary  to  be 
brought  to  the  attention  of  the  SRT  or  PMS400B.  ERT  meetings  continue  until  all 
comments  are  reviewed  and  categorized.  Completed  ERT  categorized  comments  are 
forwarded  to  the  SRT.  The  ERTs  also  generate  memos  to  the  SRT  that  outline  the 
comment  categories  and  identify  outstanding  issues. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 


APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Element  Design  Review  Teams 

Baseline  Management 

Elements 

PHDNSWC 

APL 

Government  Electronic  Systems 

System  Engineering 

None 

Backfit  Design  Review  Manual 
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Activity:  HLD-1 .4.5.4 

REVIEW  ERT  COMMENT  CATEGORIES  AND  RESOLVE  PROBLEMS 

The  SRT  is  convened  to  adjudicate  the  unresolved  ERT  comments  or  issues.  The 
chairman  directs  the  SRT  to  review  unresolved  comments  and  agree  to  any  action  category 
changes.  Action  categories  are  in  accordance  with  the  design  review  manual. 

The  SRT  chairman  documents  the  rationale  for  category  A  comments  and  any  that 
the  SRT  deems  necessary  to  bring  to  the  attention  of  PMS400B  at  the  formal  PDR.  If 
necessary,  the  ERT  chairman  is  requested  to  provide  categorization  rationale.  Completed 
SRT  categorized  comments  are  forwarded  to  NSWCDD  System  Engineering  for 
coordination,  and  to  Baseline  Management.  Recommended  changes  to  the  CDR  data 
package  are  analyzed  for  impact.  The  CDR  data  package  is  updated  in  accordance  with 
Navy  review  team  comments. 

PERFORMER:  System  Design  Review  Team 

SUPPORTING  ORGANIZATION:  System  Engineering 

Elements 

Baseline  Management 
ST&E 

APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  Backfit  Design  Review  Manual 
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1.4.6  CONDUCT  CDR  PROCESS 

The  Conduct  CDR  Process  is  comprised  of  ten  activities  as  described  below. 
Diagram  1.4.6  (Page  11-4-39)  is  a  data  flow  diagram  of  the  process  and  its  ten 
constituent  activities. 


Activity:  HLD-1 .4.6.1 

UPDATE  ELEMENT  CDR  PRESENTATION 


Element  personnel  review  the  updated  CDR  data  package  and  document  perceived 
risk  issues.  Element  personnel  prepare  required  Element  documentation  changes  including 
messages  and  common  data  definitions.  Element  personnel  update  changes  in  traceability 
to  PPSs  and  describe  any  processing  that  is  added  or  changed.  Based  upon  planned 
changes,  core  and  timing  estimates  are  developed  and  impacts  are  documented. 
Requirements  for  facilities,  equipment,  and  simulators  to  support  planned  activities  are 
described.  The  Elements  prepare  design  disclosure  information,  and  all  products  of  this 
effort  are  documented  in  the  CDR  presentation  package. 

Post-PDR  change  descriptions  (i.e.,  equipment  changes,  interface  impacts,  and 
computer  program  changes),  high-level  design  descriptions,  and  requirements  traceability 
are  supplied  by  the  Elements.  Facility/resource  availabilities  are  supplied  by  Facilities 
Engineering.  System-level  descriptions  and  risk  assessments  are  supplied  by  System 
Engineering.  The  crew  training  plan  is  supplied  by  the  AEGIS  Training  Command. 
Installation  plans,  schedules,  and  action  item  status  are  supplied  by  Baseline  Management. 


PERFORMER: 

SUPPORTING  ORGANIZATION; 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


AEGIS  Organizations 

None 

None 

None 


Activity:  HLD-1 .4.6.2 

PREPARE  SYSTEM  ENGINEERING  CDR  PRESENTATION 

System  Engineering  reviews  the  Element  design  disclosure  for  all  Elements  involved 
in  the  baseline  development  effort.  System  Engineering  personnel  develop  a  system-level 
description  of  the  functional  changes  to  the  combat  system  and  weapon  system  (including 
ORDALTs  and  firmware  changes).  The  description  may  involve  functional  flow  diagrams, 
data  flow  diagrams,  sequence  and  timing  diagrams,  configuration  description  drawings,  or 
other  description  forms,  as  appropriate,  for  conveying  the  functional  capability  and  system- 
level  significance  of  planned  changes.  System-level  technical  risk  is  updated  and  described 
based  on  design  analysis  activities. 
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PERFORMER:  System  Engineering 

SUPPORTING  ORGANIZATION:  Elements 

PMS400G 

PHDNSWC 


APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.6.3 

PREPARE  FACILITIES  ENGINEERING  CDR  PRESENTATION 


Facilities  Engineering  coordinates  with  the  Elements  and  ST&E  to  identify  the 
required  facilities.  Facilities  Engineering  performs  necessary  planning  and  coordination 
needed  to  assure  commitment  of  required  facilities,  equipment,  and  services  or  to  obtain 
acceptable  accommodations  where  requirements  cannot  be  achieved.  Facilities 
Engineering  prepares  the  facility  and  resource  availability  part  of  the  CDR  presentation 
package. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 
APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Facilities  Engineering 

Elements 

None 

None 


Activity:  HLD-1 .4.6.4 

REVIEW  TECHNICAL  CDR  PRESENTATION  MATERIAL 

System  Engineering  reviews  the  Element  design  disclosure  reflected  in  the  CDR 
data  package  for  all  Elements  involved  in  the  baseline  development.  System  Engineering 
is  responsible  for  ensuring  that  all. design  disclosure  presentations  are  technically  accurate 
and  harmonious  and  that  all  design  changes  presented  are  compatible  and  complete. 
System  Engineering  informally  discusses  and  resolves  recognized  problems  or  issues  with 
affected  Elements. 

PERFORMER:  System  Engineering 

SUPPORTING  ORGANIZATION:  Elements 
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APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.6.5 

PREPARE  BASELINE  MANAGEMENT  CDR  PRESENTATION 


Baseline  Management  prepares  an  updated  schedule  and  documents  action  item 
status.  Baseline  priorities  are  determined  and  documented  along  with  recognized  risk 
issues.  Non-MK  7  impacts  are  documented  including  schedule  and  synchronization 
problerns.  The  complete  CDR  presentation  package,  including  the  technical  parts  supplied 
by  System  Engineering  and  the  Elements,  is  discussed  with  the  NSWCDD  AEGIS  Program 
Office  for  authorization  to  proceed  to  CDR  with  the  CDR  presentation  package. 

PERFORMER:  Baseline  Management 

SUPPORTING  ORGANIZATION:  System  Engineering 

Elements 
Non-MK  7 


APPROVAL  REQUIRED:  Program  Office 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.6.6 
CONDUCT  CDR  MEETING 

Baseline  Management  facilitates  the  CDR  meeting.  Each  organization  presents  its 
approved  briefing  materials  and  makes  supporting  technical  and  management  design 
disclosure  data  available,  as  required.  A  facilities  report  is  presented  to  confirm  facility 
availability  and  commitment.  Element  and  System  Engineering  personnel  assigned  to  Navy 
review  teams  provide  CDR  presentation  support,  as  required,  in  terms  of  their  particular 
assignments.  Baseline  Management  provides  interface,  as  required,  to  permit  ATC  training 
data  for  issues  arising  subsequent  to  PDR  to  be  included  in  the  CDR  program.  Minutes  are 
recorded  and  action  item  logs  are  maintained  and  reviewed  prior  to  concluding  the  CDR. 
Upon  completion  of  CDR  presentations,  an  executive  panel  deliberates  readiness  to 
proceed  to  the  Build  Implementation  Phase  and  detailed  design.  CDR  meeting  minutes  are 
distributed  to  attendees. 


II-4-35 


27  March  1995 


High-Level  Design 


NSWCDD/MP-93/85 


PERFORMER:  Baseline  Management 

SUPPORTING  ORGANIZATION:  System  Engineering 

NSWCDD  Organizations 
ATC 

APPROVAL  REQUIRED:  PMS400 

APPLICABLE  INSTRUCTION:  None 

Activity:  HLD-1 .4.6.7 

UPDATE  TECHNICAL  DOCUMENTATION  PER  CDR  DIRECTION 

CDR  results  are  used  to  update  the  respective  baseline  development  folders.  Any 
affected  SCs  and  ICRs  are  updated  and  distributed.  Design  document  change  requests 
(DDCRs)  are  prepared  to  identify  the  required  updates  to  design  documentation. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  Baseline  Management 

System  Engineering 
Documentation  Management 
APPROVAL  REQUIRED:  None 

APPLICABLE  INSTRUCTION:  None 


Activity:  HLD-1 .4.6.8 

REVIEW  AND  APPROVE  DDCRs 

DDCRs  are  reviewed  within  the  Element  group.  The  Element  ECCB  monitors  the 
review  process  and  gives  final  approval  for  implementation  of  DDCRs  into  the  Element 
design  documents.  The  status  of  DDCRs  is  tracked  with  ACCESS. 

PERFORMER:  Elements 

SUPPORTING  ORGANIZATION:  CM 

CRB  CM 

Documentation  Management 
APPROVAL  REQUIRED:  Element  ECCB 

APPLICABLE  INSTRUCTION:  None 
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Baseline  Management  updates  the  baseline  management  plan,  as  required  by  CDR 
decisions.  Elements  update  the  Element  development  plan  in  accordance  with 
commitments  negotiated  with  Baseline  Management,  and  as  required  by  CDR  decisions. 


PERFORMER: 

SUPPORTING  ORGANIZATION: 

APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 


Baseline  Management 
Elements 

Documentation  Management 

Branch  Head 

None 


Activity:  HLD-1 .4.6.10 

UPDATE  ENGINEERING  DOCUMENTATION 

Documentation  Management  prepares  the  Element  design  document  in  accordance 
with  approved  DDCRs.  Documentation  Management,  in  consultation  with  the  affected 
Elements,  determines  whether  the  update  will  be  performed  using  change  pages  or  whether 
a  complete  design  document  re-issue  will  be  performed.  Documentation  Management 
publishes  and  distributes  the  updated  Element  design  document. 

Documentation  Management 

Elements 

Baseline  Management 
Branch  Head 
None 


PERFORMER: 

SUPPORTING  ORGANIZATION: 

APPROVAL  REQUIRED: 
APPLICABLE  INSTRUCTION: 
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5.  BUILD  IMPLEMENTATION  PHASE 


The  Build  Implementation  Phase  consists  of  a  sequence  of  one  or  more  builds 
during  which  each  unit  identified  during  the  High-Level  Design  Phase  is  developed  and 
checked  out.  Independent  of  these  builds,  support  tools  and  the  System  Test  Plan  are 
created  or  updated  as  appropriate. 

The  first  step  during  each  build  is  to  review  existing  plans  and  add  the  details 
necessary  to  govern  the  conduct  of  the  current  build.  Additionally,  each  CPCR 
identified  for  inclusion  in  a  particular  build  is  examined  to  determine  which  of  two 
alternative  processes  will  be  used  for  its  implementation. 

Small  and  simple  CPCRs  may  be  implemented  using  a  three-step  process 
consisting  of  Design  Review  and  Modification,  Code  Development  and  Checkout,  and 
Impact  Testing.  Larger  CPCRs  must  go  through  the  more  formal  process  used  for 
functional  upgrades  consisting  of  Planning  Unit  Test,  Developing  Detailed  Design, 
Developing  Unit  Test  Procedures,  and  Performing  Code  and  Unit  Test.  The  respective 
process  to  be  employed  for  each  CPCR  is  identified  in  the  Element  development  plan 
which,  upon  approval,  serves  as  the  basis  for  subsequent  QA  activities. 

Within  each  build,  different  units  scheduled  for  implementation  may  be  at 
different  steps  in  the  build  process  at  the  same  time.  For  example,  while  a  relatively 
small  unit  may  have  progressed  to  the  unit  test  step,  a  much  larger  unit  may  still  be  in 
the  detailed  design  step. 

As  units  complete  unit  testing,  they  are  packaged  with  previously  completed  units 
in  a  load  file  and  executed  with  the  rest  of  the  Element  and  other  Elements  or 
simulators.  This  results  in  a  gradual  integration  of  all  units  planned  for  development 
into  the  build  and  ultimately  with  the  rest  of  the  system. 

As  each  build  comes  to  a  close,  all  completed  units  are  executed  in  a  common 
environment  to  ensure  that  no  recently  integrated  unit  has  had  an  adverse  effect  on 
previously  tested  code.  At  the  conclusion  of  each  build,  a  Build  Implementation  Review 
(BIR)  is  conducted  where  the  results  of  all  build  activities  are  discussed.  Special 
emphasis  is  placed  on  any  facts  or  plans  disclosed  at  prior  reviews  which  might  be 
invalidated  by  the  recently  completed  build.  The  BIR  for  the  final  build  summarizes  the 
disclosures  of  the  previous  BIRs  and  serves  as  the  control  event  which  signals  the 
completion  of  the  Build  Implementation  Phase.  The  BIR  is  documented,  action  items 
are  assigned,  and  the  action  items  are  tracked  to  closure.  The  report  documenting  the 
final  BIR  is  the  control  event  that  ensures  completeness  of  all  code  and  unit  testing 
activities  for  all  builds  and  serves  as  a  status  report  to  the  Baseline  Manager. 


11-5-1 


27  March  1995 


Build  Implementation 


NSWCDD/MP-93/85 


Primary  Activities,  Products,  and  Control  Events 

Detailed  descriptions  of  the  activities  in  this  phase  are  in  preparation. 
Activities 

High-level  design  check-out 
Examination  of  CPCRs 
Design  review 

Development  of  unit  test  procedures 
Coding  and  unit  testing 
Load  file  integration 

Preparation  for  Build  Implementation  Review 
Element  and  system  test  planning 

Products 


Unit  Design  Document 
Unit  Test  Procedures 
System  Test  Plan 
Element  Test  Procedures 
Unit  Test  Reports 
Unit  Test  Limitations  Reports 
Element  QA  Reports 
Executable  Computer  Programs 
Source  Code 

Control  Event:  Build  Implementation  Reviews  (BIRs) 

Purpose:  Several  BIRs  are  conducted  to  review  the  results  of  build  activities.  For  the 
final  build,  the  BIR  is  held  to  ensure  system  design  requirements  are  met,  efficient 
program  design  has  been  achieved,  coding  and  unit  test  activities  are  complete,  and 
the  organization  is  ready  to  begin  integration  and  formal  element  testing. 

Preparer:  Element  Group  Leaders 

Coordinator:  Element  Group  Leaders 

Reviewer:  Element  QA 

Authorizing  Agent:  Element  Branch  Heads 
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6.  ELEMENT  TEST  PHASE 


In  this  phase,  each  Element  is  responsible  for  performing  PIDS  change 
validation,  computer  program  performance  change  validation,  element  integration, 
regression  testing,  stress  testing,  and  Element  interface  testing. 

To  ensure  completeness  of  Element  test  preparation,  Baseline  Management 
reviews  Element  (including  Systems  Simulation)  readiness  for  test  planning  and 
procedure  documentation  and  readiness  of  the  test  environment.  Baseline 
Management  is  responsible  for  designating  an  Element  Test  Disclosure  Review  (ETDR) 
panel  and  conducting  an  ETDR  prior  to  authorization  to  proceed  to  test  conduct. 

Each  Element  produces  (from  source  code,  patches,  and  template  files)  an 
Element  load  file  to  be  used  in  testing  in  Element  and  System  environments.  Multi- 
Element  Integration  and  Test  (MEIT)  activities  continue  in  an  iterative  manner  with 
updated  load  files.  This  effort  continues  until  a  load  file  has  completed  unit,  functional, 
interface,  and  CPCR  verification.  The  source  code  is  then  frozen  and  an  Element/QA- 
controlled  load  file  is  created. 

User  documentation  (operations  manuals  etc.)  and  System  Test  Procedures  are 
prepared. 

Formal  Element  test  is  conducted  by  running  the  test  procedures  and 
documenting  problems  via  CPCRs,  as  they  are  uncovered.  If  high-priority  problems  are 
found  during  this  phase,  they  are  patched,  independently  verified,  and  the  test 
procedure  that  uncovered  the  problem  is  rerun  In  its  entirety.  Once  all  high-priority 
problems  are  resolved  and  all  Element  tests  are  run  satisfactorily,  the  Element  Leader 
determines  that  Element  testing  is  complete.  Element  Test  Reports,  Element  Test 
Limitations  Reports,  and  System  QA  Reports  are  generated.  At  this  point,  the  Element 
files  are  passed  to  QA  for  review  and  audit. 

To  ensure  Element  development  is  sufficiently  complete  and  the  computer 
programs  are  ready  for  System  Test,  Baseline  Management  designates  an  Element 
Readiness  Review  (ERR)  panel  and  conducts  an  ERR  prior  to  authorizing 
commencement  of  System  Test. 
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Primary  Activities,  Products,  and  Control  Events 

Detailed  descriptions  of  the  activities  in  this  phase  are  in  preparation. 

Control  Event:  Element  Test  Disclosure  Review 

Purpose:  To  ensure  completeness  of  Element-level  test  planning,  test  design,  and 

test  procedure  documentation 

To  ensure  readiness  of  Elements  to  start  the  Element  Test  Phase 
To  ensure  readiness  of  ACSIS  to  support  Element  Test 

Preparer:  Elements 

Coordinator:  Baseline  Management 

Reviewer:  Elements,  ETDR  Panel 

Responsible  Agent:  Element  Branch  Heads 

Authorizing  Agent:  Baseline  Management 

Activities 


MEIT  planning,  coordination,  and  testing 
Element  stress  testing 
Element  regression  testing 

Validation  of  PIDS  SCs,  PPS  SCs,  IDS  ICRs,  and  CPCRs 
Initiation  of  source  and  patch  project  change  control 
QA  audits 

Preparation  of  System  Test  Disclosure  Review  (STDR)  package 
PDF  update 

Products 

System  Test  Procedures 
Element  Test  Reports 
Element  Test  Limitations  Report 
System  QA  Reports 
User  Documentation 
System  Test  Procedures 
Biweekly  Element  CPCR  Report 


Control  Event:  Element  Readiness  Review  (ERR) 


Purpose:  To  ensure  that  Element  development  is  sufficiently  complete  and  the 

computer  programs  are  ready  for  the  System  Test  Phase. 

Preparer:  Elements 

Coordinator:  Baseline  Management 

Reviewer:  ERR  Panel 

Responsible  Agent:  Element  Branch  Heads 

Authorizing  Agent:  Baseline  Management 
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7.  SYSTEM  TEST  PHASE 


In  the  System  Test  Phase,  Element-certified  AWS  and  non-Mk  7  computer 
programs  performing  together  as  a  combat  system  are  evaluated.  Testing  includes 
integration  of  the  computer  programs  \N\Vn  combat  system  equipment  at  a  land-based 
test  site  that  closely  replicates  the  shipboard  configuration. 

The  objectives  of  System  Test  are  to  ensure  that  the  programs  (1)  perform 
required  ship  missions  in  accordance  with  specifications,  (2)  do  not  regress  from  the 
capability  of  the  programs  being  replaced,  and  (3)  are  stable  in  use. 

The  System  Test  Disclosure  Review  (STDR)  assures  the  completeness  of 
system-level  test  planning,  test  design,  and  test  procedure  documentation  and  verifies 
readiness  to  begin  system  test.  Baseline  Management  designates  an  STDR  panel  and 
coordinates  preparation  for  and  conduct  of  the  STDR.  Upon  the  receipt  of  STDR 
approval,  system  disk  packs  are  created  or  updated  to  support  initial  ST&I.  Problems 
encountered  during  testing  are  documented  in  CPCRs  or  ST&l-controlled  test 
observation  reports  (TORs). 

Final  System  Test  is  conducted  with  trial  QA  disk  packs  created  by  Computer 
Program  Management  (CPM).  The  results  of  final  System  Test  are  documented  by 
ST&I  in  a  System  Test  Report  and  a  concerns  list  and  by  QA  in  a  System  QA  Report. 
A  Documentation  Status  Report  and  an  Installation  Plan  are  generated. 

Under  the  direction  of  the  Program  Office,  Baseline  Management  convenes  a 
Computer  Program  Certification  panel  (CPCP)  to  certify  readiness  of  the  computer 
programs  and  documentation  for  installation  in  the  fleet  and  at  shore  installations. 
Presentations  and  recommendations  to  the  CPCP  for  ship  installation  include  but  are 
not  limited  to  key  Elements,  ST&I,  QA,  and  Baseline  Management. 

Primary  Activities,  Products,  and  Control  Events 

Detailed  descriptions  of  the  activities  in  this  phase  are  in  preparation. 

Control  Event:  System  Test  Disclosure  Review 

Purpose:  To  ensure  completeness  of  system-level  test  planning,  system  test 

design,  and  test  procedure  documentation 

To  ensure  system  test  readiness  to  begin  the  System  Test  Phase 
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System  Test 
Preparer: 
Coordinator: 
Reviewer: 
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ST&I 

Baseline  Management 
STDR  Panel 


Responsible  Agent:  ST&I  Branch  Head 

Authorizing  Agent:  Baseline  Management 

Activities 

AWS  SCs  validation 
ICRs  validation 
Regression  testing 
Stress  testing 
ACS  integration  testing 
Test  analysis 
QA  audits 

Preparation  of  CPCP  packages 
TOR  evaluation  and  analysis 


Products 


System  Test  Report 
TORS 

Concerns  List 
System  QA  Report 
Installation  Plan 
Documentation  Status  Report 
Biweekly  CPCR  Report 


Control  Event:  Computer  Program  Certification  Panel 


Purpose:  To  certify  readiness  of  the  computer  programs  and  documentation  for 

installation  in  the  fleet 

To  generate  certification  letter  for  new  baseline 


Preparer: 

Coordinator: 

Reviewer: 


Baseline  Management,  QA,  ST&I,  and  Elements 

Baseline  Management 

CPCP 


Authorizing  Agent:  Program  Office 
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8.  OPERATION  PHASE 


The  Operation  Phase  begins  with  the  installation  of  computer  programs  and 
documentation  on  AEGIS  ships  and  at  AEGIS  sites.  It  continues  with  engineering 
support  of  ships  for  scheduled  trials,  ship  and  fleet  exercises,  combat  system 
experiments,  and  special  PMS400  requests,  as  well  as  ship  problem  report  review  and 
operational  process  and  product  assessment  measures. 

Fleet  Support  is  responsible  for  coordinating  all  installation  activities  with 
NSWCDD  Organizations  and  preparing  installation  plans.  Schedules  are  developed 
based  on  ship  availability  schedules  and  the  scope  of  work  to  be  performed.  Fleet 
Support  also  coordinates  activities  with  PHDNSWC,  the  ACS  ISEA. 

Shipboard  installation  media  and  documentation  are  developed  to  support 
installation.  CM  master  packs  (at-sea-configured  ship  packs)  are  created  by  CPM  from 
direction  received  from  the  Elements.  The  Elements  identify  files  to  be  removed  from 
the  master  pack  and  tapes  to  be  used  for  restoring  new  files  to  the  master  pack.  Load 
files  are  taken  only  from  QA  tapes.  Delivery  packs  are  cloned  from  the  primary  CM 
master  pack.  A  set  of  in-port-configured  tactical  packs  is  created  by  cloning  the  CM 
master  pack  onto  the  primary  in-port  pack  and  making  the  appropriate  in-port  changes. 

NSWCDD  receives  the  computer  program  media  and  documentation  from  each 
non-Mk  7  In-Service  Engineering  Agent.  Contents  of  each  package  are  controlled  and 
identified  by  transmittal  letters. 

An  Installation  Team  led  by  Fleet  Support  and  consisting  of  NSWCDD  personnel 
from  Fleet  Support,  Elements,  ST&I,  QA,  CPM,  CM,  and  Documentation  Management 
installs  and  tests  the  ACS  computer  programs  and  resolves  all  operational  problems 
associated  with  the  installation.  The  Installation  Team  also  indoctrinates  the  ship’s 
crew  and  provides  any  required  updates  to  ship  documentation. 

NSWCDD  Organizations  direct  or  support  all  subsequent  ACS  performance 
evaluations  and  improvement  efforts. 

Primary  Activities,  Products,  and  Control  Events 

Detailed  descriptions  of  the  activities  in  this  phase  are  in  preparation. 

Activities 


Generation  of  Delivery  Media 
CM  Audits 
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Installation  of  AWS  computer  programs 

Problem  report  investigation  and  impact  assessment 

Problem  report  resolution  assessment 

User  analysis  and  training  support 

QA  process  analysis 

Crew  briefing  and  indoctrination 

Delivery  of  non-Mk  7  computer  programs 

Documentation  loadout 

Installation  review  with  ship  (CO,  Combat  System  Officer,  System  Test  Officer) 
Products 


Installation  Media  (including  delivery  tapes,  disk  packs,  and  cassettes) 

Installation  Documentation  (including  tape  and  disk  pack  listings,  delivery  description 
document,  load  program  description,  data  recording/data  reduction  manual, 
computer  program  description  document,  ABAM,  users  manuals,  and 
specifications) 

Installation  Report 
Ship  Test  Report 
System  QA  Process  Report 
Validated  Problem  Reports 
Crew  Indoctrination  Package 
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